roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Johnson" <>
Subject Re: DataMapper/named-queries proposal for JDO and JPA support
Date Wed, 12 Jul 2006 20:45:34 GMT
Comments below...

On 7/12/06, Allen Gilliland <> wrote:
> I don't think that answers my original question.  Why do we need both
> jdo and jpa?  What is the connection between the two?

JDO and JPA are both persistence APIs and for each there are multiple
implemetations. For JDO, there's Kodo and JPOX and others. For JPA,
there's Hibernate JPA, OpenJPA and Glassfish JPA.  Using the Data
Mapper design, we'd be able to test a very wide range of persistence

> I don't want 2,3,4,5 backend implementations in the Roller codebase,
> that's not of any value.  We want to pick a single backend for Roller
> and that's it.  Maintaining multiple backends is a lot of extra work
> with no benefit.

Been there, done that and don't want to do it again. I think we all
agree that supporting multiple persistence libraries makes no sense.
The goal should be to pick one and only one.

> Obviously you are free to do what you like for fun or proof of concept,
> but I don't really care to have multiple backend implementations in
> Roller.  I also know that Dave had mentioned something about doing an
> ejb3 backend implementation, so that's yet another backend.

JPA is the persistence API used by EJB3. Craig killing three birds
with one stone here.

> Maybe you guys should talk about that before you do too much of this work, because
> if the Roller community decides that ejb3 is a better route to go than
> jdo then we would basically be deciding not to include the jdo stuff.

That's what we're doing now.

The reason Craig is doing this work is to help the Roller community
figure out the best way to remove our dependence on LGPL components
and choose the best persistence architecture.

> Also, personally, I have zero interest in replacing Hibernate on the
> backend.  If someone else, like you, wants to do it and we can replace
> Hibernate with something else that is equal or better and it doesn't
> cause me any heartache then that's fine.  But just so that it's clear, I
> only care about having a backend that works, not about what tool is used
> to do it.  My own opinion is that Hibernate is fine.

Hibernate's LGPL license is not acceptible for an Apache proiect.
Plus, I'd much prefer that Roller depend on a standard persistence
API, than on one vendor specific implementation.

> >> 2. I'm not sure I understand this data mapper strategy.  I thought the
> >> purpose of the XXXManager classes is already to do this work, I'm not
> >> sure I see why we need another layer of abstraction here.  Basically
> >> you are now saying that to query for something you need to call a
> >> Manager, which calls a DataMapper, which calls your ORM solution,
> >> which does the sql?

That's a good point. The main reason for the DataMapper abstraction is
to allow mutliple implementations to co-exist, but it has a couple of

- Queries are externalized and maintained in one location, so that a
DBA can examine and even tweak them without modifying source code.

- Separation of concerns is generally a good thing and the data mapper
approach separates the business/applicaiton logic from the persistence

> But going back to my comment above, I think you are essentially wasting
> your time doing multiple backend implementations.  I would just pick one
> or the other because I see no value in having both a jpa and a jdo and a
> hibernate backend.

I don't think data mapper is a waste of time because a) we'll learn a
lot by comparing JPA and JDO implementations, b) JDO and JPA are
similar enough to make the data mapper approach feasible and c) the
Data Mapper architecture is essentially good has some other benefits.

- Dave

View raw message