Re: database not suitable for use

[Karsten Hilbert]

Hello Jerzy,

thanks for chipping in with advice !

> 2024-02-15 11:03:29  DEBUG     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::__get_schema_hash_by_gm_func()
>  #605): version: 9999

GNUmed python code uses version 0 to say "this is a
development version, there's no fixed hash as yet" inside
gmPG2.py:

        known_schema_hashes = {
                0: 'not released, testing only',

        map_client_branch2required_db_version = {
                'GIT tree': 0,
                'master': 0,

as witnessed by this log line:

> 2024-02-15 11:03:29  ERROR     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::database_schema_compatible()
>  #517): expected: 0 (not released, testing only)

The SQL function to generate the hash is using logic like

        if _db_ver < 6 then
                select into _struct gm.concat_table_structure_v1();
                return _struct;
        end if;

to decide which hashing function to actually invoke which is
why the python code maps 0 to 9999 such that PostgreSQL will
always use the latest version of the hashing SQL function for
development versions:

> 2024-02-15 11:03:29  DEBUG     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::__get_schema_hash_by_gm_func()
>  #605): version: 9999

This will always lead to a mismatch of hashes:

> 2024-02-15 11:03:29  DEBUG     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::__get_schema_hash_by_gm_func()
>  #608): hash: 3a9dc575763bcfa852f80bd52b2ff902
> 2024-02-15 11:03:29  ERROR     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::database_schema_compatible()
>  #516): database schema version mismatch
> 2024-02-15 11:03:29  ERROR     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::database_schema_compatible()
>  #517): expected: 0 (not released, testing only)
> 2024-02-15 11:03:29  ERROR     gm.db         [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/Gnumed/pycommon/gmPG2.py::database_schema_compatible()
>  #521): detected: <unknown> (3a9dc575763bcfa852f80bd52b2ff902)

which will make gmPG2.database_schema_compatible() fail
always. However, when running a devel version from the git
tree, which is what Bruno is doing, GNUmed will (should) warn
but not fail if --override-schema-check is given as a command
line argument which it was:

> 2024-02-15 11:03:21  INFO      gm.launcher   [139668927156288 MainThread]  
> (/home/gnumed/gnumed/gnumed/gnumed/client/gnumed.py::__log_module_sys() 
> #599): argv: ['gnumed.py', '--conf-file=gm-from-vcs.conf', 
> '--log-file=gm-vcs-02_15--11_03_21--3279.log', '--override-schema-check', 
> '--local-import', '--debug']

GNUmed does (should) show a bunch of warning dialogs before
proceeding to ignore the mismatch which is what I was
wondering about ...

Thanks for prompting me to double-check the flow control logic !

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B