Re: Thoughts on object stores: JPA vs JDO

[Jeroen van der Wal <je...@stromboli.it>]

To add more food for though I would like to point to Spring Data JPA
[1] with built in support for QueryDSL.

"As a developer you write your repository interfaces, including custom
finder methods, and Spring will provide the implementation
automatically. ... Spring JPA also takes the concept of a
specification from Eric Evans' book Domain Driven Design, that carries
the same semantics and provides an API to define such Specifications
using the JPA criteria API."

Maybe its an idea to start a wiki page pros and cons of various approaches?

Cheers,
Jeroen

[1] http://www.springsource.org/spring-data/jpa





On Thu, May 31, 2012 at 9:14 AM, Dan Haywood
<da...@haywood-associates.co.uk> wrote:
>
> [note: Jeroen and I have been discussing this topic off-list.  So it's
> right that Jeroen has posted this here, to see what other opinions are].
>
> Jeroen,
> I have to say I'm of the same mind as you...  Isis shouldn't have lots of
> proprietary persistence code in it, it should instead be leveraging other
> open source work and their communities.
>
> As you might have seen from the commits, I've started work on resurrecting
> a JPA object store, using Apache OpenJPA as the implementation.  And to
> answer your specific question, although JDO is arguably better than JPA as
> a general persistence platform, to me it still is a niche compared to JPA,
> and it would hinder Isis if it only supported JDO and not JPA.
>
> But I also think that JDO looks like a good solution for every *other*
> object store out there; in other words I think that Isis should support
> both.  In particular, I like the fact that there are integrations for NoSQL
> and things like Google BigTable [1].  My only main reservation is that it
> might  make sense to target JDO 2.0 rather than 3.x, though, since only
> DataNucleus as an implementation currently supports 3.x
>
> The other question you raised was with regard to type-safe queries.  Those
> links you posted were interesting - I didn't realize that Java's APT could
> be used to generate metamodels like this and thus create a (rather ugly)
> Java equivalent to .NET's LINQ.  And it seems that querydsl also integrates
> with Eclipse m2e (through an m2e connector for the maven-apt-plugin) so
> this is seems viable approach.
>
> Given that querydsl runs on both JPA and JDO, perhaps that ought to be the
> lingua-franca for typesafe queries in Isis?
>
> ~~~
> Going back to the more fundamental point you are raising here, I think that
> once we have both a JPA and a JDO object store impl, that we should
> consider junking *all* of our current object stores (in-memory, XML, NoSQL
> and SQL OS).  There would of course be substantial impact for the user
> community if we do this, but then again, while we still have only a small
> community, it's feasible to consider.  In-memory object stores could be
> simulated by using either JPA or JDO using an HSQLDB mem: database.
>
> The benefit is that we could substantially slim down the runtime component
> of Isis.  The heart of this is the ObjectAdapter class, that: (a) wraps the
> underlying pojo, (b) holds a reference to the OID, (c) holds a reference to
> the ObjectSpecification (cf java.lang.Class in the Isis metamodel) and (d)
> tracks the "ResolveState", basically whether the object is transient or
> persisted, and if persisted what it's lazy loading state is and whether it
> is dirty (needs to be saved).
>
> It's the last of these that could be simplified.  Indeed, if only JPA and
> JDO are supported, these both have sophisticated lazy-loading and
> dirty-tracking logic; much more sophisticated  than Isis' built-in support.
>  With the Hibernate-based object store I did previously, I found myself
> having to write lots of complicated logic to get Isis' ResolveState to
> match the lazy loading state of the Hibernate.  What I'm considering doing
> for the OpenJPA implementation is to mostly ignore ResolveState, and merely
> track whether the object is persistent or not.  In fact, I might even go
> further: there's an internal API for creating ObjectAdapters (the
> ObjectAdapterFactory), so what I might do is to install a custom
> implementation that returns ObjectAdapters whose getResolveState() method
> always throws an exception.  If that works, then I know that in principle
> it'd be safe to remove this functionality in the future.
>
> The above is obviously clashes with some of Isis' original philosophy to
> build everything in-house.  But to some extent the fact that Isis does so
> much itself is due to the age of some of the codebase... when originally
> written, JDO and JPA standards didn't even exist.
>
> Bottom line: I think that having less proprietary code in Isis will make it
> simpler to maintain, make it more attractive to would-be users, and would
> allow Isis to focus on its core value-add (a stonkingly good metamodel,
> OIDs as an abstraction for runtime objects, and of course the generic
> viewers and REST).
>
> Like you, Jeroen, I'd be interested in thoughts from others.
>
> Cheers
> Dan
>
> [1] http://db.apache.org/jdo/impls.html
>
>
> On 31 May 2012 00:03, Jeroen van der Wal <je...@stromboli.it> wrote:
>
> > I ran into an Issue of implementing an object store using Apache EmpireDB
> > https://issues.apache.org/jira/browse/ISIS-222 which triggered me to share
> > my thoughts on object stores.
> >
> > I definitely don't want to stop intentions to implement more object stores
> > within Isis but personally I prefer the use of a standards compliant Java
> > API like JPA or JDO and select an implementation with an Apache2 license
> > (OpenJPA, Datanucleus) as a reference. It's future proof and users can
> > replace it with a different provider if they need better performance or, in
> > the case of JDO, exotic object stores. Also we can rely on other
> > communities to maintain the various implementations and providers.
> >
> > When choosing between JPA and JDO I found some interesting stuff, looks too
> > me that JPA is targeted solely to RDBMS:
> > http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html
> > http://db.apache.org/jdo/jdo_v_jpa.html
> >
> > If our goal is to have a type-safe API (I'm a big fan of string free
> > coding) then QueryDSL (JPA, JDO) or DataNucleus (JDO) could be added to the
> > mix:
> > http://datanucleus.blogspot.com/2010/11/jdo-typesafe-vs-jpa-criteria.html
> > http://www.querydsl.com/modules
> >
> > I'm interested your thoughts on this.
> >
> > Kind Regards,
> >
> > Jeroen van der Wal
> >

Re: Thoughts on object stores: JPA vs JDO

[Dan Haywood <da...@haywood-associates.co.uk>]

Hmm, Interesting stuff.  Thx for that.

I remember meeting Oliver Gierke, the guy who worked on the Hades open
source project and that seeded this piece of work, at a conference a few
years ago.  Must admit I didn't really get what he was trying to do back
then.  But it's nice for him that it's been folded into Spring... kudos.

I'll check out their implementation, for sure.  But I don't want to bring a
hard dependency on Spring itself... that's just a bit too much bloat for my
liking.

Also, given that querydsl uses APT and so requires IDE support (eg [1]),
some users I'm sure would prefer not to use it and rely on string-based
JPQL.  So this must be an optional component somehow.

Not sure if we need a wiki page on this; I don't have much else to say on
the topic right now.  But by all means create one if you'd like to
summarize this thread.

Cheers
Dan

[1] https://github.com/ilx/m2e-querydsl


On 31 May 2012 23:26, Jeroen van der Wal <je...@stromboli.it> wrote:

> To add more food for though I would like to point to Spring Data JPA
> [1] with built in support for QueryDSL.
>
> "As a developer you write your repository interfaces, including custom
> finder methods, and Spring will provide the implementation
> automatically. ... Spring JPA also takes the concept of a
> specification from Eric Evans' book Domain Driven Design, that carries
> the same semantics and provides an API to define such Specifications
> using the JPA criteria API."
>
> Maybe its an idea to start a wiki page pros and cons of various approaches?
>
> Cheers,
> Jeroen
>
> [1] http://www.springsource.org/spring-data/jpa
>
>
>
>
>
> On Thu, May 31, 2012 at 9:14 AM, Dan Haywood
> <da...@haywood-associates.co.uk> wrote:
> >
> > [note: Jeroen and I have been discussing this topic off-list.  So it's
> > right that Jeroen has posted this here, to see what other opinions are].
> >
> > Jeroen,
> > I have to say I'm of the same mind as you...  Isis shouldn't have lots of
> > proprietary persistence code in it, it should instead be leveraging other
> > open source work and their communities.
> >
> > As you might have seen from the commits, I've started work on
> resurrecting
> > a JPA object store, using Apache OpenJPA as the implementation.  And to
> > answer your specific question, although JDO is arguably better than JPA
> as
> > a general persistence platform, to me it still is a niche compared to
> JPA,
> > and it would hinder Isis if it only supported JDO and not JPA.
> >
> > But I also think that JDO looks like a good solution for every *other*
> > object store out there; in other words I think that Isis should support
> > both.  In particular, I like the fact that there are integrations for
> NoSQL
> > and things like Google BigTable [1].  My only main reservation is that it
> > might  make sense to target JDO 2.0 rather than 3.x, though, since only
> > DataNucleus as an implementation currently supports 3.x
> >
> > The other question you raised was with regard to type-safe queries.
>  Those
> > links you posted were interesting - I didn't realize that Java's APT
> could
> > be used to generate metamodels like this and thus create a (rather ugly)
> > Java equivalent to .NET's LINQ.  And it seems that querydsl also
> integrates
> > with Eclipse m2e (through an m2e connector for the maven-apt-plugin) so
> > this is seems viable approach.
> >
> > Given that querydsl runs on both JPA and JDO, perhaps that ought to be
> the
> > lingua-franca for typesafe queries in Isis?
> >
> > ~~~
> > Going back to the more fundamental point you are raising here, I think
> that
> > once we have both a JPA and a JDO object store impl, that we should
> > consider junking *all* of our current object stores (in-memory, XML,
> NoSQL
> > and SQL OS).  There would of course be substantial impact for the user
> > community if we do this, but then again, while we still have only a small
> > community, it's feasible to consider.  In-memory object stores could be
> > simulated by using either JPA or JDO using an HSQLDB mem: database.
> >
> > The benefit is that we could substantially slim down the runtime
> component
> > of Isis.  The heart of this is the ObjectAdapter class, that: (a) wraps
> the
> > underlying pojo, (b) holds a reference to the OID, (c) holds a reference
> to
> > the ObjectSpecification (cf java.lang.Class in the Isis metamodel) and
> (d)
> > tracks the "ResolveState", basically whether the object is transient or
> > persisted, and if persisted what it's lazy loading state is and whether
> it
> > is dirty (needs to be saved).
> >
> > It's the last of these that could be simplified.  Indeed, if only JPA and
> > JDO are supported, these both have sophisticated lazy-loading and
> > dirty-tracking logic; much more sophisticated  than Isis' built-in
> support.
> >  With the Hibernate-based object store I did previously, I found myself
> > having to write lots of complicated logic to get Isis' ResolveState to
> > match the lazy loading state of the Hibernate.  What I'm considering
> doing
> > for the OpenJPA implementation is to mostly ignore ResolveState, and
> merely
> > track whether the object is persistent or not.  In fact, I might even go
> > further: there's an internal API for creating ObjectAdapters (the
> > ObjectAdapterFactory), so what I might do is to install a custom
> > implementation that returns ObjectAdapters whose getResolveState() method
> > always throws an exception.  If that works, then I know that in principle
> > it'd be safe to remove this functionality in the future.
> >
> > The above is obviously clashes with some of Isis' original philosophy to
> > build everything in-house.  But to some extent the fact that Isis does so
> > much itself is due to the age of some of the codebase... when originally
> > written, JDO and JPA standards didn't even exist.
> >
> > Bottom line: I think that having less proprietary code in Isis will make
> it
> > simpler to maintain, make it more attractive to would-be users, and would
> > allow Isis to focus on its core value-add (a stonkingly good metamodel,
> > OIDs as an abstraction for runtime objects, and of course the generic
> > viewers and REST).
> >
> > Like you, Jeroen, I'd be interested in thoughts from others.
> >
> > Cheers
> > Dan
> >
> > [1] http://db.apache.org/jdo/impls.html
> >
> >
> > On 31 May 2012 00:03, Jeroen van der Wal <je...@stromboli.it> wrote:
> >
> > > I ran into an Issue of implementing an object store using Apache
> EmpireDB
> > > https://issues.apache.org/jira/browse/ISIS-222 which triggered me to
> share
> > > my thoughts on object stores.
> > >
> > > I definitely don't want to stop intentions to implement more object
> stores
> > > within Isis but personally I prefer the use of a standards compliant
> Java
> > > API like JPA or JDO and select an implementation with an Apache2
> license
> > > (OpenJPA, Datanucleus) as a reference. It's future proof and users can
> > > replace it with a different provider if they need better performance
> or, in
> > > the case of JDO, exotic object stores. Also we can rely on other
> > > communities to maintain the various implementations and providers.
> > >
> > > When choosing between JPA and JDO I found some interesting stuff,
> looks too
> > > me that JPA is targeted solely to RDBMS:
> > > http://www.datanucleus.org/products/accessplatform/jdo_jpa_faq.html
> > > http://db.apache.org/jdo/jdo_v_jpa.html
> > >
> > > If our goal is to have a type-safe API (I'm a big fan of string free
> > > coding) then QueryDSL (JPA, JDO) or DataNucleus (JDO) could be added
> to the
> > > mix:
> > >
> http://datanucleus.blogspot.com/2010/11/jdo-typesafe-vs-jpa-criteria.html
> > > http://www.querydsl.com/modules
> > >
> > > I'm interested your thoughts on this.
> > >
> > > Kind Regards,
> > >
> > > Jeroen van der Wal
> > >
>