[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 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 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/ #231): 
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 
(./ #1248): failed to import 
2009-10-27 22:18:55  ERROR     gm.bootstrapper 
(./ #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
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 
psql:../sql/v8-v9/dynamic/v9-clin-health_issue-dynamic.sql:112: NOTICE:  issue: 
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/ #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/ #231): 
relation "audit.log_substance_brand" does not exist
2009-10-27 23:22:41  ERROR     gm.bootstrapper 
(./ #1248): failed to import 
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]