isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: Thoughts on object stores: JPA vs JDO
Date Thu, 31 May 2012 07:14:54 GMT
[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].

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.



On 31 May 2012 00:03, Jeroen van der Wal <> wrote:

> I ran into an Issue of implementing an object store using Apache EmpireDB
> 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:
> 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:
> I'm interested your thoughts on this.
> Kind Regards,
> Jeroen van der Wal

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message