[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