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

[Ian Haywood]

On Sat, 17 Apr 2004 12:55:07 +0200
Karsten Hilbert <address@hidden> wrote:
> > 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 ?
gmPatient.cPatientSearcher_SQL.get_patient_ids ():
gets a list of patient IDs (i_id on v_basic_person) Then for each person we are 
going back and fetching the other fields
by separate queries. We could do one query (select * from v_basic_person where 
....) to do the whole thing at once.

> > 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 ?
Hmm, I see now that it gets messy if we confuse the role of the VO constructor 
between a new
middleware object and constructing a new backend object as well.

> > >   _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.
Locking will delay the concurrent update, but it will still happen, just later.
With transactions the change occurs now but it's hidden (for the first user) 
until later. 
What's the difference? (except locking slows things down) Is it the auditing 
mechanism
that forbids concurrency?

Ian
-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgpYFWVprqB3f.pgp
Description: PGP signature