roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Gilliland <allen.gillil...@sun.com>
Subject Re: DataMapper/named-queries proposal for JDO and JPA support
Date Wed, 12 Jul 2006 23:38:09 GMT
more comments ...


Dave Johnson wrote:
> Comments below...
> 
> 
> On 7/12/06, Allen Gilliland <allen.gilliland@sun.com> 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
> libraries.

got it.  thanks.


> 
> 
>> 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.

exactly.  you will find me a very grumpy and bastardly person if you try 
and suggest that you want to commit all these various backends into 
Roller.  i am already weary of simply swapping one backend for another.


> 
> 
>> 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.

cool.  then why are we talking about doing jdo?  sorry, i don't keep up 
with all these persistence apis as much as i should, but i don't see the 
benefit of continually swapping them around.


> 
> 
>> 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.

i see.


> 
> 
>> 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.

personally i don't consider either of those real incentives to change 
the backend, but that's coming from a customers point of view.  since 
Hibernate works fine and I don't have any legal problems with using it 
then its way more trouble to worry about switching it than it is to just 
leave it as far as i'm concerned.

for folks who run large Roller installations it is a very big and 
troubling change to swap out an entire backend strategy, so it's not 
something that i look forward to at all.  and at the end of the day 
making that change does not provide a single benefit for existing users. 
  i guarantee that most roller users could care less about the 
apache/hibernate licensing issue and whether or not roller user 
hibernate vs. jpa.


> 
> 
>> >> 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
> side-benefits:
> 
> - Queries are externalized and maintained in one location, so that a
> DBA can examine and even tweak them without modifying source code.

umm, what queries?  all of our queries are handled by our ORM solution.

plus, you can externalize your queries with or without this data mapper, 
so it's not like that's a unique feature that the data mapper adds.


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

but, that's what the manager interfaces already do.  they separate 
business logic like getWeblogEntries(x, y, z) from persistence logic 
like "select * from weblogentry ...".

the data mapper is really just another sublayer of abstraction which i 
said i didn't see the benefit of.  maybe if i could see a more flushed 
out proposal for how this data mapper will work then i'll understand it 
better.


> 
> 
>> 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.

I don't understand, you said above that ... "the goal is to pick one and 
only one."

So why would we design our code to add extra complexity which allows us 
to more easily support multiple implementations if we don't even want 
multiple implementations?  what do we learn by comparing various 
implementations?  why go to that effort?  even if jdo and jpa are 
similar enough that this data mapper will help, why spend the time to 
develop both when we know we are only going to use one of them?

i am certainly confused about what our direction is with this new 
backend work.  i don't understand why we aren't just picking a single 
approach/tool and using that, whether it's jdo or jpa or something else.

-- Allen


> 
> - Dave

Mime
View raw message