continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Wed, 03 Jan 2007 04:14:59 GMT
Yeah.  But to have truly pluggable persistence, then we end up having to 
pick LCD features.  For isntance, if we want JDO, iBatis, and 
JPA/Hibernate as possible approaches, then our design has to pretty much 
ignore transparent relationship manifestation that JPA/hibernate/Toplink 
provide.  True, the Store API could be common, but the assumptions about 
the objects returned will be different. 

For example, if we were using a JPA/Hibernate approach, then we could 
have something in the style of:

ProjectGroup group = store.get(ProjectGroup.class,"myGroup");
for (Project project : group.getProjects().iterator()) {
   do stuff;

But we would have to do a lot more work to get that for iBatis, for 
example, which merely maps the tables/queries to classes, without any 
assumptions about relationships.  So we couldn't have the same object 
model persisted and manifested from the same store impl, and get hte 
same behavioural assumptions.  If we went with the LCD features, then we 
could implement it with iBatis, spring-jdbc, hibernate, jpa or anythign, 
but we aren't really dealing with an articulated object model any more, 
but an objectified set of tables.  Our code would be highly 
functional/relational, rather than OO.  On the other hand, if we wanted 
to go the higher road, we could still provide abstractions that could be 
implemented using Hibernate/Toplink/WebObjects-EOF/JPA, since they all 
share transparent mapping and manifestation of relationships.

So the choice here is what level of abstraction do we want, and what 
functionality do we want to have to implement in our model, and what do 
we want to implement via the persistent store mechanism.

We also need to ask ourselves what we gain by over-abstraction. What are 
the actual benefits if swapping store implementations.  What are the 
expected scenarios where this would happen.  I honestly don't think 
we're going to find many.  At most, I think we're going to move between 
an O/R mapping framework to a pure OO database.  But even that I doubt.  
If it's just swapping in/out new RDBMS back-ends, most of the above 
transparent persistence mechanisms already support a large variety of such.

Having said all of that, my vote (which no one need care about, since I 
haven't had much time to actually contribute code here) is to support 
hibernate with slight abstraction on top of it (modeled on JPA's entity 
manager), so we get the benefits of transparent persistence without 
requiring Java 5.0 - at least until we get to the point where we can run 
in java 5 but execute maven/ant in java 1.4 and earlier.  Once we are at 
that point, maybe we can move to JPA (which is a small delta), or at 
least update the abstraction some.

If we were to decide that, hey, screw jdk 1.4, let's just go with java5, 
then I'd just suggest going for JPA as the abstraction.  It's got 
problems, but everything does, and it's an increasingly adopted standard 
with some decent implementations.


Rahul Thakur wrote:
> These buzzwords have been making rounds on IRC and dev list :-), and 
> after slight digging around I found a reference to a similar 
> discussion here:
> Agreed that the store implementation for Continuum should be 
> pluggable, and if we are rethinking JPOX, then IMHO it might be worth 
> taking into account JPA and Java 5.0.
> What do others think?
> Cheers,
> Rahul


*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** + bus 905.640.1119 + mob 416.998.6023*

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