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