[Top][All Lists]

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

Re: [Gnumed-devel] GnuMed EMR browser

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] GnuMed EMR browser
Date: Thu, 12 Aug 2004 14:52:22 +0200
User-agent: Mutt/

>       - rationalising use of SQL. Unfortunately AFAICT the VO concept
> has led to a very inefficient way of interacting with the backend:
Only where many items are concerned at once. Unfortunately,
that's the case most of the time :-)

Note, that it doesn't change the GUI-side API in the least
whether value objects fetch themselves one-by-one or in a big
get-the-data query with subsequent local instantiation. The
only difference the frontend will find is in the speed of the
returning query.

> Although it may be better OO design that VOs
> encapsulate the queries used to populate themselves,
I would eventually do it like this:

frontend calls emr.get_lab_data()

emr.get_lab_data() returns cache if hot
emr.get_lab_data() makes one big fetch, locally instantiates
VOs, caches and returns cache

Eg. the frontend will see no difference.

> Because it is *unusable*, IMHO we need to grapple with
> this now, normally I would agree with the priniciple of "get it working
> first, then optimise"    
Well, the other option would be to eventually write the async

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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