gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] report on java client prototype.


From: s j tan
Subject: [Gnumed-devel] report on java client prototype.
Date: Sat, 06 Sep 2003 01:13:52 +1000

The java client in test-area/gnmed can  do the following input outputs:
1)       create new patient , open patients in multiple windows
2)       modify patient demographic details
3)       modify social id details
4)       add, update, delete past history
5)       add, update, delete medications
6)       create, update providers for referrals, but not create new
provider types yet.
7)       generate summary referral letters to providers on patients, and
print them , but does not record the referral letter action
8)       generate script previews, and print them, but does not record
the script printing action
 
It requires configuration to run:
It depends on 1)j2sdk1.4 ( perhaps jre1.4.2 only enough), 2)ant package
to compile , 3)hibernate 2.0 package as middleware OR mapper.
( Copy the ant and hibernate library jar files into the lib directory) 
It requires configuration of database username and password in
hibernate.properties.
It requires loading of database by running ant task testLoadPostcode,
then overlaying the drugref schema database and data
By using psql -f org.drugref.schema.dump  template1  , psql -f
org.drugref.data.schema.dump.
 
Non-lazy loading of identities was found to slightly decrease the
debugging of database communication, but not much; 
The debugging tended to occur in checking generated hibernate
configuration files;
the separate source build directories' convention with ant make stops
the netbeans debugger working, as well as hibernate
having lots of debug breakpoints , which I haven't learnt how to turn
off , so debugging was blackbox via the logger or print statements.
 
Non-lazing  / lazy loading cannot be configured dynamically, which would
be handy for search identities. Easier probably just to use
direct sql in this case, or have a mutable=false read-only view class
that maps to the same tables.
 
The connection is everything in transactional modification of objects ;
a lot of unexpected errors had to be debugged because
hibernate does not allow modification of a object through more than one
session/connection, and multiple threads do not share
the same session object . I didn't get a good handle of how to easily
use proxied associations, so that the patient identity object
had to be loaded largely as a whole (non-lazy) , which is good for
making updates a cinch ( just one command, save(), and 
the OR mapper cascades all the updates through the associations) , but
can take a significant amount of time, and I haven't
yet tried to parcel off this save time into another thread, which would
be difficult as mentioned before about session per thread 
separation. 
So like anything it's a tradeoff using an OR mapper; some people would
be more comfortable with fine grained handwritten
sql statements. I still like hibernate though ( having wasted most of my
spare time in the last 2 months on it).
 
 
 





reply via email to

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