[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] <bug> bootstrap database: not existing table referenc
From: |
Jerzy Luszawski |
Subject: |
Re: [Gnumed-devel] <bug> bootstrap database: not existing table referenced in v7->v8 |
Date: |
Wed, 28 Oct 2009 00:25:52 +0100 |
User-agent: |
KMail/1.9.10 |
Tuesday 27 October 2009 11:51:34 Karsten Hilbert napisaĆ(a):
> > I have found that in module gmNotificationSchemaGenerator.py a
> > table 'message_inbox' is referenced, while it is known under this name
> > only since v12 (previously: 'provider_inbox').
>
> True enough, it was renamed because it can now be used for
> messages generically, not limited to provider bound messages.
>
> > Reverting this name in the gmNotificationSchemaGenerator.py solved the
> > problem for me, but I think it requires more attention.
>
> Yes. The proper fix is to disable generating audit and
> notification schema objects below v12 (in CVS HEAD, that
> is) which I did.
>
> > Also dem.trf_announce_provider_inbox_generic_mod_no_pk() remains in v12
> > (shouldn't it be dropped?)
>
> It should and in fact there's explicit code to do so in
> v12-dem-message_inbox-dynamic.sql under sql/dynamic/ which
> is also duly included in the .conf file. So you may want to
> double-check with the above fix.
>
> Checked in.
I tried to bootstrap it, but was stuck at different place:
--- log file:
2009-10-27 22:18:55 ERROR gm.bootstrapper
(/home/jlk/gnumed-CVS/gnumed/gnumed/Gnumed/pycommon/gmPsql.py::run() #231):
../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:111:
record "old" has no field "id_patient"CONTEXT: PL/pgSQL function
"ft_upd_health_issue" line 5 at SQL statementSQL statement "update
clin.health_issue set fk_encounter = $1 where pk =
$2 "PL/pgSQL function "tmp_add_encounters_to_issues" line 43 at SQL statement
2009-10-27 22:18:55 ERROR gm.bootstrapper
(./bootstrap_gm_db_system.py::_import_schema() #1248): failed to import
[../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql]
2009-10-27 22:18:55 ERROR gm.bootstrapper
(./bootstrap_gm_db_system.py::bootstrap() #1112): Cannot import schema
definition for bundle [v8-v9-dynamic] into database [gnumed_v9].
--- when trying it under psql:
gnumed_v9=> \i ../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql
COMMENT
psql:../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:20: NOTICE: drop
cascades to trigger tr_ensure_issue_encounter_patient_consistency on table
clin.health_issue
DROP FUNCTION
CREATE FUNCTION
CREATE TRIGGER
CREATE FUNCTION
psql:../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:112: NOTICE: issue:
1
psql:../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:112: NOTICE:
creating new encounter
psql:../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:112: NOTICE:
linking issue (1) <-> encounter (7)
psql:../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:112: ERROR: record
"old" has no field "id_patient"
CONTEXT: PL/pgSQL function "ft_upd_health_issue" line 5 at SQL statement
SQL statement "update clin.health_issue set fk_encounter = $1 where pk = $2 "
PL/pgSQL function "tmp_add_encounters_to_issues" line 52 at SQL statement
----------------------------------
This did not happen previously.
After the investigation i changed back "audit disable" to 0 in
update_db-v7_v8,conf and update_db-v7_v8.conf, and the bootstrapping went on,
until v11->v12:
---------- log:
2009-10-27 23:22:41 DEBUG gm.bootstrapper
(/home/jlk/gnumed-CVS/gnumed/gnumed/Gnumed/pycommon/gmPsql.py::run() #226):
alter table audit.log_substance_brand
add column external_code text
2009-10-27 23:22:41 ERROR gm.bootstrapper
(/home/jlk/gnumed-CVS/gnumed/gnumed/Gnumed/pycommon/gmPsql.py::run() #231):
../sql/v11-v12/static/v12-clin-substance_brand-static.sql:19:
relation "audit.log_substance_brand" does not exist
2009-10-27 23:22:41 ERROR gm.bootstrapper
(./bootstrap_gm_db_system.py::_import_schema() #1248): failed to import
[../sql/v11-v12/static/v12-clin-substance_brand-static.sql]
--------------------------------
I did the same for update_db-v10_v11.conf ( "audit disable = 0") and finally
got v12 ready.
I have checked-in these small changes to CVS.
Wouldn't it be better to disable all auditing before upgrading database?
BTW: Since which database version the notification schema is used? v12?
Jerzy Luszawski