gnumed-bugs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karsten Hilbert
Subject: Re: [Gnumed-bugs] Unhandled exception entering a new lab test into a patient measurement
Date: Thu, 8 Jan 2015 15:43:32 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Thu, Jan 08, 2015 at 11:35:01AM +0100, Karsten Hilbert wrote:

> 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 ?

For what it's worth, I can't reproduce the bug with code
newer than 1.4.9.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]