Re: [Gnumed-bugs] GNUmed 1.5.0 - invalid [v19] schema structure

[Karsten Hilbert]

On Thu, Jan 15, 2015 at 08:52:40AM +0000, Jim Busser wrote:

> I am not sure whether there is anything wrong with the v19 database that I 
> restored from backup

Thankfully not.

>, or whether there is a bug in the code which attempts to do
> 
>       sh upgrade-db.sh 19 20

Neither.

> but after getting as far as
> 
>       ...
>       =======================================
>       Bootstrapping GNUmed database system...
>       =======================================
>       You are about to install the following parts of GNUmed:
>       -------------------------------------------------------
>       bundle "v19_fixups-pre_v20" in <gnumed_v20> (or overridden) on <>
>       bundle "v19-v20-static" in <gnumed_v20> (or overridden) on <>
>       bundle "v19-v20-dynamic" in <gnumed_v20> (or overridden) on <>
>       -------------------------------------------------------
> 
>       ==> bootstrapping "v19_fixups-pre_v20"
>       ... I need the password for the database user [postgres].
>       Please type the password: 
> 
> I got stuck with the generic terminal message
> 
>       "cannot bootstrap bundles" 
> 
> while the detail in the log shows
> 
>       2015-01-15 00:24:03  ERROR     gm.bootstrapper 
> (./bootstrap_gm_db_system.py::__create_db() #771):
>               invalid [v19] schema structure in GNUmed template database 
> [gnumed_v19]
>       2015-01-15 00:24:03  ERROR     gm.bootstrapper 
> (./bootstrap_gm_db_system.py::__bootstrap() #599): Cannot create database.
>       2015-01-15 00:24:03  ERROR     gm.bootstrapper 
> (./bootstrap_gm_db_system.py::bootstrap() #1309): Cannot bootstrap bundle 
> [v19_fixups-pre_v20].
> 
> Log attached. Also the fingerprint log for the v19 that I restored.

Your fingerprint says:

                Name: gnumed_v19
         Schema hash: 9765373098b03fb208332498f34cd4b5
                Size: 313 MB
            Patients: 357
            Contacts: 938
            Episodes: 551
              Issues: 150
             Results: 78
        Vaccinations: 1
           Documents: 190
             Objects: 303

Do those numbers make sense ?

Now, looking at

         Schema hash: 9765373098b03fb208332498f34cd4b5

if we go to client/pycommon/gmPG2.py we see

        map_schema_hash2version = {
                ...
                'a0f9efcabdecfb4ddb6d8c0b69c02092': 18,
                #'419e5225259c53dd36ad80d82066ff02': 19 # 19.0 only
=>              #'9765373098b03fb208332498f34cd4b5': 19 # until 19.11
                '57f009a159f55f77525cc0291e0c8b60': 19, # starting with 19.12

so you've actually got a valid v19 (< v19.12) schema.

99% of fixup scripts do not change the hash. Therefore, the
upgrader a) does run the fixups before the upgrade but b)
also requires the initial hash to be a known good state.

The fixup runner, however, ignores the initial hash and just
applies the fixups (since some might actually change the hash
and the fixup script is _intended_ to unbork things if
possible).

So (in this case, because there _are_ fixups changing the hash
between your v19 version and the final v19):

        cd server/bootstrap/
        ./fixup-db.sh 19
        ./upgrade-db.sh 19 20

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346