Re: database not suitable for use

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