roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Gilliland <>
Subject Re: DataMapper/named-queries proposal for JDO and JPA support
Date Thu, 13 Jul 2006 16:12:20 GMT
I agree with basically everything that Anil said.  I have a couple more 
comments inline ...

Anil Gangolli wrote:
> My perspectives:
> (1) Let's choose just one persistence API.  I think we've all expressed
> agreement on that.


> (2) The driving motivation I see for switching from Hibernate:  we're 
> trying
> to become an Apache project; we would like to get rid of non-compatibly
> licensed dependencies so that we can ship a complete running product 
> without
> requiring a separate support package.  We originally entered the Incubator
> hoping we would resolve the LGPL issues and be able to do this with
> Hibernate.  Since that now looks impossible, a choice is necessary.  I
> personally favor sticking with Apache and finding an alternative to
> Hibernate that we can ship.  I know others might disagree.  Perhaps a 
> vote is appropriate.   The prospect of choosing an API that still
> supports Hibernate as an alternative implementation (so deployers can 
> plug in Hibernate) is attractive in principle, but we all know that in 
> terms of practical
> support it and the implemenation we ship probably will get hard.  I'd 
> prefer to get multi-database support working better for the range of 
> databases we want to support.

in my case i basically lack any motivation to switch away from 
Hibernate.  i know that there is the licensing issue, but it doesn't 
affect me personally, so i see switching the backend as a great risk 
with a reward that i don't even care about.

however, as Anil said, if we can swap the backend to something else and 
make it a smooth transition then that's fine.  i'm not exactly eager to 
contribute time to this effort though.

> (3) Remember that switching to another API isn't enough; we should also 
> make sure we have a good (robust, reasonably fast, compatibly licensed) 
> implementation that we can ship.   We need to determine both an API and 
> a suitable (default) implementation.

i agree.  at the end of the day our users don't care at all how the 
backend is implemented, they just expect it to work out of the box.  so 
we need to just pick a single direction to go and make a solid 
implementation out of it.

> (4) I was really hoping for more guidance in the API choice, to the extent
> that (with consultation) we would even make the API  choice without
> experimentation, and restrict the experimentation to determining a good
> default implementation to ship, including some performance benchmarks
> against the current Hibernate one and verifying operation on our supported
> databases.  Experimenting on so many axes at once seems like it is way
> beyond the scope of what we can get right.

this is a very good point.  i think it's a good idea to play around a 
bit and evaluate our options, but i don't think we need to go through 
the pain of doing a whole set of implementations.  i don't have strong 
feelings about what api/implementation we use, as long as it's equal or 
better than Hibernate.

> (5) I don't see a need for the additional layer.  First, if we choose the
> API early, I think we can avoid the need for the additional layer
> altogether.  Second, even if we don't choose the API early, I think we 
> could move the current Criteria and query formation to the Strategy 
> layer; I don't see the difference between named queries and method names 
> on an interface for the Strategy layer, and I feel the latter is 
> simpler.  My opinions on this aren't as strong as long as we end up with 
> something no harder to maintain/change than the present code.

this is basically the point i was trying to get across in my emails.  if 
we are only going to pick a single implementation to do then i don't see 
the need for this additional data mapper layer of abstraction.

if it really does help then that's fine, but i think Martin Nilsson's 
point about how it adds a runtime dependency with the way those queries 
are specified.  that part definitely makes me a bit nervous as well.

-- Allen

View raw message