|
| From: | Busser, Jim |
| Subject: | [Gnumed-bugs] v17 ... v19 bootstrapping and client unable to access resulting v19 |
| Date: | Mon, 11 Nov 2013 23:07:24 +0000 |
|
The apparent dependence (v18 … v19) to designate an org unit as the primary praxis location
Upgrading "gnumed_v18" to "gnumed_v19" did not finish successfully.
caused me to wonder about the upgrade path from v17 to v19. Accordingly, for test purposes, I overwrote my restored v18 by doing
Dads-MacBook:bootstrap root# sh upgrade-db.sh 17 18
and then did
upgrade 18 19
but it seems that the resulting v19 lacks the org unit to be set, preventing the client to be able to access it?
See attached
-- Jim
===========================================================
Upgrading GNUmed database: v17 -> v18
This will create a new GNUmed v18 database from an
existing v17 database. Patient data is transferred and
transformed as necessary. The old v17 database will
remain unscathed. For the upgrade to proceed there must
not be any connections to it by other users, however.
The name of the new database will be "gnumed_v18". Note
that any pre-existing v18 database WILL BE DELETED
during the upgrade !
(this script usually needs to be run as <root>)
===========================================================
1) creating backup of existing database ...
Note that this may take a substantial amount of time and disk space!
You may need to type in the password for gm-dbo.
Password:
2) upgrading to new database ...
Adjusting PYTHONPATH ...
=======================================
Bootstrapping GNUmed database system...
=======================================
You are about to install the following parts of GNUmed:
-------------------------------------------------------
bundle "v17_fixups-pre_v18" in <gnumed_v18> (or overridden) on <>
bundle "v17-v18-static" in <gnumed_v18> (or overridden) on <>
bundle "v17-v18-dynamic" in <gnumed_v18> (or overridden) on <>
bundle "v18-fixups" in <gnumed_v18> (or overridden) on <>
-------------------------------------------------------
This will update an existing GNUmed version 17
database to the version 18 schema. It does not do
any harm to the data contained within.
The existing database will be cloned first. The copy is
then modified. The original database remains unchanged.
Do you really want to install this database setup ?
Type yes or no: yes
==> bootstrapping "v17_fixups-pre_v18" ...
I need the password for the database user [postgres].
Please type the password:
==> dropping pre-existing target database [gnumed_v18] ...
==> cloning [gnumed_v17] (49 MB) as target database [gnumed_v18] ...
==> transferring users ...
==> bootstrapping "v17-v18-static" ...
==> bootstrapping "v17-v18-dynamic" ...
==> bootstrapping "v18-fixups" ...
==> setting up auditing ...
==> verifying FKs on clin.clin_root_item child tables ...
==> setting up generic notifications ...
==> setting up (old style) notifications ...
==> upgrading reference data sets ...
==> verifying target database schema ...
... skipped (devel version)
==> checking migrated data for plausibility ...
==> sanity checking PostgreSQL authentication settings ...
Note that even after successfully bootstrapping the GNUmed
database PostgreSQL may still need to be configured to
allow GNUmed clients to connect to it.
In many standard PostgreSQL installations this amounts to
adding (or uncommenting) the authentication directive:
"local samerole +gm-logins md5"
in the proper place of the file:
/Library/PostgreSQL/9.1/data/pg_hba.conf
For details refer to the GNUmed documentation at:
Done bootstrapping GNUmed database: We very likely succeeded.
log: /private/tmp/gnumed-server.19.0/server/bootstrap/update_db-v17_v18.log
==========================================================
Make sure to upgrade your database backup procedures to
appropriately refer to the new database "gnumed_v18" !
==========================================================
Dads-MacBook:bootstrap root# sh upgrade-db.sh 18 19
===========================================================
Upgrading GNUmed database: v18 -> v19
This will create a new GNUmed v19 database from an
existing v18 database. Patient data is transferred and
transformed as necessary. The old v18 database will
remain unscathed. For the upgrade to proceed there must
not be any connections to it by other users, however.
The name of the new database will be "gnumed_v19". Note
that any pre-existing v19 database WILL BE DELETED
during the upgrade !
(this script usually needs to be run as <root>)
===========================================================
1) creating backup of existing database ...
Note that this may take a substantial amount of time and disk space!
You may need to type in the password for gm-dbo.
Password:
2) upgrading to new database ...
Adjusting PYTHONPATH ...
=======================================
Bootstrapping GNUmed database system...
=======================================
You are about to install the following parts of GNUmed:
-------------------------------------------------------
bundle "v18_fixups-pre_v19" in <gnumed_v19> (or overridden) on <>
bundle "v18-v19-static" in <gnumed_v19> (or overridden) on <>
bundle "v18-v19-dynamic" in <gnumed_v19> (or overridden) on <>
-------------------------------------------------------
This will update an existing GNUmed version 18
database to the version 19 schema. It does not do
any harm to the data contained within.
The existing database will be cloned first. The copy is
then modified. The original database remains unchanged.
Do you really want to install this database setup ?
Type yes or no: yes
==> bootstrapping "v18_fixups-pre_v19" ...
I need the password for the database user [postgres].
Please type the password:
==> dropping pre-existing target database [gnumed_v19] ...
==> cloning [gnumed_v18] (56 MB) as target database [gnumed_v19] ...
==> transferring users ...
==> bootstrapping "v18-v19-static" ...
==> bootstrapping "v18-v19-dynamic" ...
==> setting up auditing ...
==> verifying FKs on clin.clin_root_item child tables ...
==> setting up generic notifications ...
==> setting up (old style) notifications ...
... skipped (disabled)
==> upgrading reference data sets ...
==> verifying target database schema ...
==> checking migrated data for plausibility ...
==> sanity checking PostgreSQL authentication settings ...
Note that even after successfully bootstrapping the GNUmed
database PostgreSQL may still need to be configured to
allow GNUmed clients to connect to it.
In many standard PostgreSQL installations this amounts to
adding (or uncommenting) the authentication directive:
"local samerole +gm-logins md5"
in the proper place of the file:
/Library/PostgreSQL/9.1/data/pg_hba.conf
For details refer to the GNUmed documentation at:
Done bootstrapping GNUmed database: We very likely succeeded.
log: /private/tmp/gnumed-server.19.0/server/bootstrap/update_db-v18_v19.log
==========================================================
Make sure to upgrade your database backup procedures to
appropriately refer to the new database "gnumed_v19" !
==========================================================
Dads-MacBook:bootstrap root# cd /Users/dad/Downloads/gnumed-client.1.4.0/client
Dads-MacBook:client root# sh gm-from-vcs.sh
-------------------------------------------------
gm-from-vcs.sh: line 49: git: command not found
Running from Git branch:
-------------------------------------------------
GNUmed startup: GNUmed should not be run as root.
-------------------------------------------------
Running GNUmed as <root> can potentially put all
your medical data at risk. It is strongly advised
against. Please run GNUmed as a non-root user.
Dads-MacBook:client root# xit
-sh: xit: command not found
Dads-MacBook:client root# exit
logout
Dads-MacBook:client dad$ cd /Users/dad/Downloads/gnumed-client.1.4.0/client
Dads-MacBook:client dad$ sh gm-from-vcs.sh
-------------------------------------------------
gm-from-vcs.sh: line 49: git: command not found
Running from Git branch:
-------------------------------------------------
Running from local source tree (/Users/dad/Downloads/gnumed-client.1.4.0) ...
Adjusting PYTHONPATH ...
/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/wxpython/gmGuiMain.py:3600: wxPyDeprecationWarning: Call to deprecated item 'InitAllImageHandlers'.
wx.InitAllImageHandlers()
Error in sys.excepthook:
Traceback (most recent call last):
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/wxpython/gmExceptionHandlingWidgets.py", line 230, in handle_uncaught_exception_wx
wx.EndBusyCursor()
File "/usr/local/lib/wxPython-2.9.5.0/lib/python2.7/site-packages/wx-2.9.5-osx_cocoa/wx/_misc.py", line 322, in EndBusyCursor
return _misc_.EndBusyCursor(*args)
wx._core.PyAssertionError: C++ assertion "gs_wxBusyCursorCount > 0" failed at /BUILD/wxPython-src-2.9.5.0/src/osx/cocoa/utils.mm(394) in wxEndBusyCursor(): no matching wxBeginBusyCursor() for wxEndBusyCursor()
Original exception was:
Traceback (most recent call last):
File "gnumed.py", line 631, in <module>
gmGuiMain.main()
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/wxpython/gmGuiMain.py", line 3604, in main
app = gmApp(redirect = False, clearSigInt = False)
File "/usr/local/lib/wxPython-2.9.5.0/lib/python2.7/site-packages/wx-2.9.5-osx_cocoa/wx/_core.py", line 8631, in __init__
self._BootstrapApp()
File "/usr/local/lib/wxPython-2.9.5.0/lib/python2.7/site-packages/wx-2.9.5-osx_cocoa/wx/_core.py", line 8196, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/wxpython/gmGuiMain.py", line 3071, in OnInit
if not self.__verify_praxis_branch():
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/wxpython/gmGuiMain.py", line 3283, in __verify_praxis_branch
if not gmPraxisWidgets.set_active_praxis_branch(no_parent = True):
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/wxpython/gmPraxisWidgets.py", line 412, in set_active_praxis_branch
branches = gmPraxis.get_praxis_branches()
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/business/gmPraxis.py", line 136, in get_praxis_branches
rows, idx = gmPG2.run_ro_queries(queries = [{'cmd': cmd}], get_col_idx = True)
File "/Users/dad/Downloads/gnumed-client.1.4.0/Gnumed/pycommon/gmPG2.py", line 1190, in run_ro_queries
curs.execute(query['cmd'], args)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/psycopg2/extras.py", line 120, in execute
return super(DictCursor, self).execute(query, vars)
psycopg2.ProgrammingError: relation "dem.v_praxis_branches" does not exist
LINE 1: SELECT * FROM dem.v_praxis_branches WHERE true
^
Dads-MacBook:client dad$
|
| [Prev in Thread] | Current Thread | [Next in Thread] |