Thread: JDO implementation?

        For the past few weeks, I've been working on what I'd thought of
as an 'object database emulation layer', which would allow me to store
Java objects in a PostgreSQL database in much the same way that a
typical object database would.  Needless to say, I was doing this
naively, based on raw need and the fact that there was currently no
decent, free apparatus to enable transparent persistent storage of Java
objects.   (It's to the point where schema translation and object
marshalling are fully functional.  I'm using AspectJ to enable me to
provide transparency.)

        Needless to say, I had not heard about JDO
(http://softwaredev.earthweb.com/java/article/0,,12082_918111,00.html).
 Has there been any discussion amongst the development team about
providing a JDO implementation for PostgreSQL?  (Sun's plan seems to be
to let the database vendors implement an interface (which is almost
finalized, and very similar to OMG's specifiction for an OODB interface,
with some extra java-centric things thrown in) that their expert group
has written.  They've provided a reference implementation which is
ostensibly a starting point for said vendors and an example store which
writes flat files.) It seems like it would be a great thing to be able
to provide this sort of functionality.  I'm still trying to figure out
who (say, Oracle et al) is planning adopting the interface and providing
an implementation and on what schedule they plan on doing so, but I
personally know many, many people who would flock to a free-software
solution to transparent persistence for Java.  If there's a current
effort being made toward this goal, I'd love to help out.  If not, I'd
like to give it a try!

        Any thoughts, or ideas?  Is everyone already doing this without
me? =)

    -dj trombley
      <dtrom@bumba.net>

Dave

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.

I have been using it mostly as part of the overall Turbine framework,
which can be found on the same site and although there are some teething
problems with postgres, it seems promising.

hth
colm

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>