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.
Christian.
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:
http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/msg01251.html
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** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
