Re: [Gnumed-bugs] Unhandled exception entering a new lab test into a patient measurement

[Karsten Hilbert]

On Thu, Jan 08, 2015 at 12:24:29AM +0000, Jim Busser wrote:

> I got an unhandled exception when I inputted a never-before used lab test, 
> which I had not created ahead of time.
> 
> The UE manifest itself after I had inputted what I had thought was enough 
> information, and when I was trying to save it.
> 
> Seemingly there is a problem when GNUmed is trying to assign the new test 
> type, in this case
> 
>       AST
> 
> to an org unit and maybe owes itself to a change within GNUmed as to which 
> org is used by default?

Here is what happens. GNUmed tries to create a test type.

>  File 
> "/Users/djb/Downloads/gnumed-client.1.4.9/Gnumed/business/gmPathLab.py", line 
> 863, in create_measurement_type
>    lab = create_test_org()['pk_test_org']

The lab is not given:

> 2015-01-07 15:55:47  DEBUG     gm.lab 
> (/Users/djb/Downloads/gnumed-client.1.4.9/Gnumed/business/gmPathLab.py::create_measurement_type()
>  #849): creating test type [None:AST:AST:U/L]

Hence GNUmed creates one:

>  File 
> "/Users/djb/Downloads/gnumed-client.1.4.9/Gnumed/business/gmPathLab.py", line 
> 81, in create_test_org
>    unit = name

> def create_test_org(name=None, comment=None, pk_org_unit=None):
...
>       if name is None:
>               name = u'unassigned lab'
>
>       # get org unit
>       if pk_org_unit is None:
>               org = gmOrganization.org_exists(organization = name)
>               if org is None:
>                       org = gmOrganization.create_org (
>                               organization = name,
>                               category = u'Laboratory'
>                       )

Including a new org unit:

>               org_unit = gmOrganization.create_org_unit (
>                       pk_organization = org['pk_org'],
>                       unit = name
>               )

which tries to create the org unit:

> def create_org_unit(pk_organization=None, unit=None):
>
>       args = {'desc': unit, 'pk_org': pk_organization}
>
>       # exists ?
>       cmd = u'SELECT pk FROM dem.org_unit WHERE description = %(desc)s AND 
> fk_org = %(pk_org)s'
>       rows, idx = gmPG2.run_ro_queries(queries = [{'cmd': cmd, 'args': 
> args}], get_col_idx = False)
>       if len(rows) > 0:

and finds it already created and therefore returns it as an
object created from its primary key:

>               return cOrgUnit(aPK_obj = rows[0][0])

however, that fails:

>  File 
> "/Users/djb/Downloads/gnumed-client.1.4.9/Gnumed/business/gmOrganization.py", 
> line 299, in create_org_unit
>    return cOrgUnit(aPK_obj = rows[0][0])

> 2015-01-07 15:55:47  ERROR     gm.db 
> (/Users/djb/Downloads/gnumed-client.1.4.9/Gnumed/pycommon/gmBusinessDBObject.py::refetch_payload()
>  #551): [cOrgUnit:21825]: no such instance

Now, the existence search ran against the base table
dem.org_unit (that's faster) while the object instantiation
works against the denormalizing view dem.v_org_units (it
needs more data than the base table holds). Hence the
disagreement over org unit existence may arise from that
fact.

And, indeed, a commit for 1.4.10 talks about the relevant
database objects:

> commit b0903cfb2809946e880eab17d231d52e57490d4b
> Author: Karsten Hilbert <address@hidden>
> Date:   Sat Jun 28 14:16:42 2014 +0200
>
>    Fix orgs/units views to properly show entries w/o categories
>
>        - INNER JOINs must be LEFT JOINS because org/units may not have 
> categories

In other words, the 1.4.9 views might not have shown some
orgs/units that did, however, exist in the base table.

Can you please upgrade to at least 1.4.10 and report whether
the issue disappears ?

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