Re: [INTERFACES] query java object?

Joe,

Tomorrow we're going to release a new version of Castor that does just
that. It's being developed and tests with PostgreSQL (what else) so you
can bet it's PostgreSQL complaint.

It does Java persistence into SQL tables by mapping Java fields to SQL
columns, supports one-one and many-one relationships, inheritance,
locking, the whole enchilada.

This release only includes the ODMG API, the next release (two weeks
from now) will include the CMP API as well (EJB 1.1 compliant) plus OQL
for describing finders.

The next release will also integrate with Tyrex for JTA transaction
management, 2 phase commit, etc. I've been in contact with Peter about
adding X/A support to the next release of the PostgreSQL JDBC driver to
support distributed transactions.

I'm doing the final touches on the source code right now and will have a
release to download tomorrow.

Oh, the link: http://castor.exolab.org

arkin

Joe Shevland wrote:
>
> Hi all,
>
> OK, hopefully this all makes sense...
>
> <background>
> The enterprise java beans spec specifies that classes
> requiring (CMP) persistence need to let the container know
> which attributes to persist by way of an XML
> descriptor.
> </background>
>
> So, given that we only want to persist certain properties/attributes
> of a particular Java class is this possible using the mechanism
> described below?
>
> Also, what are the overheads involved here? I guess the table
> will need to be created the first time an object of a particular
> type is stored, after that it should fairly normal?
>
> I'd love to be able to come up with a container-managed-persistence
> module based on PostgreSQL for EJBOSS (www.ejboss.org), but
> I'm still sorting things out in my head as to the best ways of doing this.
>
> One little weird one, given that the Java classes you persist actually
> persist other classes they reference (as long as they're defined in
> PostgreSQL mapping I guess), would a way around the cyclic
> reference problem be to check the .equals() method when storing
> chained objects, maintain a hashtable for each root node and not
> store the object if it has already been done? That seems awfully
> simplistic, what are the issues involved?
>
> Regards,
> Joe.
>
> ----- Original Message -----
> From: "Peter Mount" <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
> To: "'Phillip Rhodes'" <rhodespc(at)bellatlantic(dot)net>;
> "'pgsql-interfaces(at)postgresql(dot)org'" <pgsql-interfaces(at)postgreSQL(dot)org>
> Sent: Thursday, January 06, 2000 1:50 AM
> Subject: RE: [INTERFACES] query java object?
>
> > Yes of sorts. We have a small extension that allows a Serialized object
> > to be stored in one or more tables (rather than as a stream). Once
> > serialized in this way, you can then query the stored objects just like
> > any other SQL Table.
> >
> > Peter
> >
> > --
> > Peter Mount
> > Enterprise Support
> > Maidstone Borough Council
> > Any views stated are my own, and not those of Maidstone Borough Council.
> >
> >
> >
> > -----Original Message-----
> > From: Phillip Rhodes [mailto:rhodespc(at)bellatlantic(dot)net]
> > Sent: Monday, January 03, 2000 2:11 AM
> > To: 'pgsql-interfaces(at)postgresql(dot)org'
> > Subject: [INTERFACES] query java object?
> >
> >
> > I read through the documentation for Postgres and Java, but I am a
> > little
> > unclear on something: (probably a few things!)
> >
> > Is it possible to execute a query based on the attributes of a
> > serialized
> > object? Or do I have to instantiate each object and do an if test?
> >
> >
> > Thanks!
> >
> > Phillip
> >
> >
> >
> > ************
> >
> > ************
> >
>
> ************