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