Re: [Gnumed-devel] gmPG higher-level features?

[Karsten Hilbert]

> I've been working on business/gmTmpPatient.py, to try to
> extend it to be a demographics middleware layer.
> (perhaps it should be called gmTmpPerson now??)
:-)  It should have right from the beginning. Once we consider
putting more work into it and even renaming the thing we might
just drop the Tmp, too. I put that in so we are reminded that
this didn't come out of a consensus but merely out of my
keyboard because I needed something then and there.

> Looking at the code, I'm not sure why we can't have 3 functions in
> gmPG:
>         run_select (service, query, args)
Isn't that what run_query already does ?  What part of *query*
would you propose to move into the hardwired logic suggested
by the _*select* part of run_select() ?

>         run_update (service, query, args)
Good idea insofar as getting updates right (MVCC -> serialize
-> duplicate key insertion error) is somewhat tricky.

> these cache connections and cursors as appropriate, take care
> of error reporting, grab read or read/write connections as
> appropriate, etc.
The business objects already cache data at the business logic
level. Read-only connections are cached at the gmPG level.
Caching cursors may or may not be beneficial depending on the
situation and should perhaps be done in the business object ?

I have always supported the idea of evolving generic
functionality out of actively developed code. You've been
working on gmTmpPatient so I figure you've found a need for
your proposed helper functions. I'd say go ahead and show
their use in some places. They needn't be mandatory to use,
though, just as run_query isn't (can be replaced by any
handrolled loop of try: cursor.execute() except: ...  if you
are willing to type a lot :-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346