Re: JDO implementation?

Michael Ansley wrote:

> I believe that Castor already support Postgres.  I'm not sure if this
> is exactly what you are looking for, but from what I've read in the
> manuals and instructions, it's probably pretty close.


Colm McCartan wrote:

> I don't know if its quite what you are looking for, but have you seen
> the Jakarta Torque Project (
> http://jakarta.apache.org/turbine/torque/index.html )? It is built on
> the Village API which is itself (roughly) an abstraction of JDBC.


    These systems are similar to what I'm doing in that they both
provide a way of translating a java class storage schema into a database
table for some RDBMS and provide storage.  What they do not do, however,
is provide an OMG-like interface to the stored objects (full transaction
model, class extents, object queries, etc).  The other major feature
they do not include is /transparent/ storage.  The idea is that someone
using the database should never need to know that they are using a
database! With transparent storage, you don't have to explicitly
allocate space for an object, you don't have to explicitly start a
transaction, you don't have to explicitly store an object, instead you
simply use the persistent object as you would any other and the OODB
takes care of the rest.  Since Java does not expose much of the JVM to
the language, this is somewhat difficult, and requires cheating.  (For
example, one thing I needed to do was to have one of my functions get
called back every time a member variable was accessed for reading or
writing in any persisted class)  One way to 'cheat' is to mangle the
source of the persistent objects before compiling them.  The system I've
been using, AspectJ, does exactly that.  The JDO framework takes a
different approach, and will mangle the actual bytecode to provide
exactly the hooks needed for transparency.  (this potentially solves one
of the problems i've had - i currently can't update an object's storage
state when it is accessed reflectively)

    In addition to this, I've noticed that both of the systems mentioned
above translate schemas into XML as an intermediate step.  This is great
if you want to use that XML in some other way, perhaps to publish
objects in another XML-enabled tool or on the web, but it incurs
overhead to parse and traverse XML constructs.

    -dj trombley
      <dtrom@bumba.net>