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.
