[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 <[email protected]> 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 >
