roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anil Gangolli" <a...@busybuddha.org>
Subject Re: DataMapper/named-queries proposal for JDO and JPA support
Date Thu, 13 Jul 2006 14:34:45 GMT
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.

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

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

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


Mime
View raw message