Re: [Gnumed-devel] Gnumed Value Objects dev guide, draft 1

[Karsten Hilbert]

> >       - Each instance verifies its existence upon instantiation.
> I'm still worried this is going to get slow, especially when returning long 
> lists of VOs.
This is a valid concern. We can always drop the check if speed
turns out to be a limiting factor. Also

list1 = emr.get_lab_results()
list2 = emr.get_lab_results()

will only instantiate objects once (unless the DB notified a
change in lab result data *for that patient*), list2 will be a
copy of lab_results from cache

> Better to have a single query which grabs a list of object PKs *and* fields 
> to instantiate VOs en bloc.
Can you expand on that ?

> >     - Creation of new entries in the database is NOT supported
Not from *within* (or by means of) a cClinItem object.
Adopting this rule spares us a lot of ugly special cases.

> I assume instead there are factory methods on gmClinicalRecord for each VO 
> class.
Yes, like add_lab_result().

> gmClinicalRecord could end up rather large in this case.
It IS large. Just think of those overflowing paper charts. A
paper chart affords attachment of another lab sheet. So does
gmClinicalRecord. It affords adding a lab result record.

> Would it be better to let VO classes have a constructor which takes the 
> gmClinicalRecord of the current
> patient as a parameter, if only to distribute code around files a bit more.
How exactly would you like this to work ?

> >     _cmds_store_payload: It's important to perform row locking before 
> > writting operation.
> Why is this? commits are isolated from each other on postgres anyway. 
Uhm, ha ?!? We still need to select for update right before
updating to prevent another commit to update our row under the
cover. We need to protect against concurrent updates.

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