Tim Cook wrote:
> > Now, I'm just completing on a generic Java object-relational
> > mapper to SQL RDBMS and PostgreSQL or SQL3 ORDBMS. It works
> > pretty nicely already. I then put on top of it a reduced
> > form of the HL7 USAM (only key features since I don't care
>
> Gunther,
> This is very interesting. I'm not sure what you mean as far as generic
> though. When I think of 'mapping', I have someplace to start and someplace
> to go. Please elaborate.
Simple: every Java object that inherits from my PersistentObject class
has the method
void save(PersistenceBroker)
and
void save()
The PersistenceBroker is an interface with the user method
PersistentObject load(java.lang.Class, OID oid)
and soon some query (by example) methods.
What is generic about it is: you can define the mapping of java
classes to tables and java fields to columns in the data base
(dictionary, two simple tables ps_class and ps_field.) For field
mapping you can choose between the following kinds
- direct -- object is written into the db field, typical for primitives
- inline -- a composite object is inlined into the container table
useful for composite values without identity (e.g. numeric
interval (low/high), measurement (value/unit) etc.)
- reference to-one -- the object id (OID) of the associated object
is written into the db field. An additional flag CASCADE_SAVE
allows you to always save the associated object automatically.
- reference to-many -- the object id (OID) of this object is written
into the forreign key field of each of the associated objects and,
depending on the CASCADE_SAVE flag, the other objects are saved
too.
The PersistenceBroker interface comes in two implementations right now
RelationalBroker -- for MySQL, or HypersonicSQL and all that
ObjectRelationalBroker -- for PostgreSQL
in addition I may add two XML brokers, an indexed XML file broker
(GDBM) and a sequential XML file broker ... but I'm stil mentally
recovering from too much XML and too little data bases.
The nice thing about my persistence package is that the client objects
don't have to have any special interface (like in COBRA) rather, just
like JOS, any field can be stored and retrieved from the data base if
it is defined in the data dictionary (no special accessor methods
required.) If a non-transient field is not in the dictionary, you get
a warning but it still continues. The only stuff that persistent objects
may want to implement is a special static constructor method so that
the default constructor can be private. And a call-back method
void notifyRestored()
that is called by the broker when a persistent object awakes from it's
sleep (to recalculate transient values, etc.)
So, it's very seamless.
Now I'm gonna add the on-demand object loading feature (for to-many
associations) and the query feature. I'm hoping that some other
pair of eyes and hands might whant to check the concurrency behavior
of this package (which I am currently not too concerned with) The
goal is to make it thread safe on the Java side and concurrency-safe
on the DB side. If everything works O.K. I release this stuff early
next week.
regards,
-Gunther
--
Gunther_Schadow-------------------------------http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1050 Wishard Blvd., Indianapolis IN 46202, Phone: (317) 630 7960
[EMAIL PROTECTED]#include <usual/disclaimer>
begin:vcard
n:Schadow;Gunther
tel;fax:+1 317 630 6962
tel;home:+1 317 816 0516
tel;work:+1 317 630 7960
x-mozilla-html:FALSE
url:http://aurora.rg.iupui.edu
org:Regenstrief Institute
adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA
version:2.1
email;internet:[EMAIL PROTECTED]
title:M.D.
fn:Gunther Schadow
end:vcard
