I have not dug into this, but a friend of mine raves about it:
http://www.softwaretree.com/products/jdx/Jdx1.htm
Can anyone compare/contrast features between this and Torque?
Peter - how does this jive with your wish list?
Erik
----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: "Jakarta General List" <[EMAIL PROTECTED]>
Sent: Thursday, April 25, 2002 9:09 PM
Subject: Re: Subproject Proposal - crossdb
On Fri, 26 Apr 2002 09:20, Jon Scott Stevens wrote:
> on 4/25/02 3:37 PM, "Peter Donald" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > As a side note. I have heard good things about
> > http://hibernate.sourceforge.net/ which is yet another persistence
layer.
> > Unlike all the other ones this does not force you to work within a
> > particular model of development. ie It does not force you to regenerate
> > sources (ie Torque), postcompile (ie Entity beans), or process it
through
> > bytecode augmenter (ie JDO).
> >
> > The persisted objects are simple java beans with setters and getters.
The
> > setters/getters need not be public but the system will only persist
> > javabean properties.
> >
> > Anyways it looks like a very kool idea but I have not yet tried it. And
> > before I jump into it I was wondering if anyone else has had a go? The
> > main thing I guess I am interested in is the performance as none of its
> > docs talk about how they cache instances of javabeans or when the beans
> > are made stale etc.
>
> I like their quote in their FAQ...
>
> "And, at runtime, reflection isn't really as slow as people say."
>
> The reality is that reflection in pre-JDK 1.4 is terribly slow compared
> with direct method calls.
1.3 reflection is a little better but the earlier stuff truly sucks ;)
However the speed of reflection is such a minor part in persistence layer I
could not see how it would effect performance. Especially given that you are
going through jdbc possibly over IP to get to the underlying DataSource.
What I guess the main performance characteristeric will be how they handle
the
instance cache, invalidation and so forth. Unfortunately I can't see any
stuff on their websote regarding that.
> FYI, Torque's re-generation of sources is really not that big of a deal.
Depends on how often the schema changes ;) Or if you need to map it in
different ways in different systems.
However the main reason that I was looking at this was because the
persistence
layers suck in a distributed application. You end up creating dummy Value
Objects for each persisted object or for each view which are 90% identical
to
actual persistent objects (minus the persistence framework specific parts).
Sou you end up with something like following in torque
MyData (The Biz Object)
MyDataVO (The Value Object)
MyDataPeer (The Peer)
AbstractMyData (the abstract biz object)
AbstractMyDataPeer (The abstract Peer)
And the only one decoupled from the persistence framework is MyDataVO. In an
ideal situation you would just have a single object "MyData" that is free
from persistence framework and is nice and simple. (and basically a clone of
MyDataVO). The rest of the stuff could be dynamically configured at
runtime -
including the mapping to physical datasource.
Any system that did that and did not have all the rest of the cruft would be
a
sure winner IMHO.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
