Re: [Gnumed-bugs] GNUmed 1.5.0 - needs one more fixup relating to test orgs?

[Busser, Jim]

On 2015-01-15, at 10:40 PM, Karsten Hilbert <address@hidden> wrote:

> On Thu, Jan 15, 2015 at 05:52:15PM +0000, Jim Busser wrote:
> 
>> I seem to have gotten past the schema requirements, except it seems my 
>> database contains data that violates a constraint that v20 would like to 
>> apply, and preventing me from completing the upgrade. The problem is:
>> 
>>       insert or update on table "test_org" violates foreign key constraint 
>> "test_org_fk_org_unit_fkey"DETAIL:  Key (fk_org_unit)=(1) is not present in 
>> table "org_unit".
> 
> A real bug !  :-))
> 
> Lookee here:
> 
>               insert into clin.test_org (fk_org_unit, comment)
>               select
>                       (select 1 from dem.org_unit where
>                               description = 'branch of unknown laboratory'
>                                       and
>                               fk_org = (select pk from dem.org where 
> description = 'unknown laboratory')
>                       ),
>                       'auto-generated by v20-clin-test_type-dynamic.sql'::text
>               where not exists (
>                       select 1 from clin.test_org where fk_org_unit = (
> =>                            select 1 from dem.org_unit where
>                                       description = 'branch of unknown 
> laboratory'
>                                               and
>                                       fk_org = (select pk from dem.org where 
> description = 'unknown laboratory')
>                       )
>               )
> 
> => this must be "select pk from dem.org_unit where" ...
> 
> That's why I always hope for people to test the upgrade with
> their respective databases. It worked in all three of mine
> (deploy, devel, public) since all of them do have a
> clin.test_org the fk_org_unit of which just so happens to be 1 :-)
> 
> Fixed for 1.5.2 to be released today.

it seems that in spite of the failed upgrade 19 20, the script succeeded to 
create the following v20, making me wonder whether the script needs a tweak, if 
it is desired to AVOID leaving behind a v20 where new db constraints were 
unable to be applied on account of the data particulars in the old v19 …

    Fingerprinting GNUmed database ...
    
                    Name: gnumed_v20
             Schema hash: 946e9ac2be6d2d28c1a8c556c6a267d3
                    Size: 314 MB
                Patients: 357
                Contacts: 938
                Episodes: 551
                  Issues: 150
                 Results: 78
            Vaccinations: 1
               Documents: 190
                 Objects: 303
           Organizations: 12366
    Organizational units: 11485
            Version (PG): 9.3.1
           Encoding (PG): UTF8
         LC_COLLATE (PG): en_CA
           LC_CTYPE (PG): en_CA

-- Jim