more comments inline ...
Craig L Russell wrote:
Hi Allen,
First, sorry for missing this message the first time around. As you
probably know, Sun was on its 4th of July break all last week...
On Jun 30, 2006, at 11:44 AM, Allen Gilliland wrote:
Taking a quick look at the proposal and have a few thoughts ...
1. Can I get some more explanation about the connection between jdo
and jpa? Why do we need implementations of both?
When I first looked at implementing XXXManager for JDO, I started with
the Hibernate implementation and in doing that work, realized that most
of the code was simply translating the XXXManager interface code to
XXXStrategy code. All of the datamapper implementations have the same
notion of making a transient Java instance persistent, removing the
persistent representation, etc. And when I considered adding a jpa
implementation as well, it became clear that I didn't want to have jdo
and jpa implementations with 90% of the code common without an
abstraction that made the common code common and not simply copied.
I don't think that answers my original question. Why do we need both
jdo and jpa? What is the connection between the two?
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.
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. 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.
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.
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?
Pretty close to what the Hibernate implementation does, except with the
datamapper abstraction, the XXXManager code is actually identical. With
the current Hibernate code, you call the HibernateXXXManager, which
calls the HibernatePersistenceStrategy, which calls the Hibernate ORM
APIs which do the SQL. So the thing I'm doing is abstracting common code.
It also feels a little bit like reinventing the wheel since based on
the example code I saw there will be a new query convention for using
the data mapper. So now I need to do extra work because I need to
understand how to use this custom data mapper language with
"getByPingTarget&&website", and I still need a data mapper
implementation which parses the data mapper queries and translates
them into queries in my ORM tool.
Yes, here there is another layer that is needed to look up the name of
the query getByPingTarget&&website and find the mapper-specific query.
The actual implementation of the query may simply delegate to the
mapper-specific "lookup query by name", as implemented by jdo and jpa.
Or it might use a local hashmap to find the query implementation.
I haven't used this pattern before so I'm sure I don't fully
understand how it's supposed to work, but I'm not seeing the benefit
so far.
If you can appreciate that we would want to support both jdo and jpa, I
think it's worthwhile to actually make common code from the
application-specific XXXManager implementations instead of simply
copying and pasting code from Hibernate to jdo-specific XXXManager and
then copying and pasting code from jdo-specific XXXManager to
jpa-specific XXXManager.
I am like everyone else, I hate duplicating code, especially if it's
just tedious code to work on. If you want to implement this data mapper
then that's fine, but it sounds much more complex than what the
HibernatePersistenceStrategy class does to me.
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.
-- Allen
Thanks for the feedback,
Craig
-- Allen
Dave Johnson wrote:
Adding Craig to the CC list.
- Dave
On 6/29/06, Dave Johnson <[EMAIL PROTECTED]> wrote:
Craig Russell has updated his JDO backend proposal to use a data
mapper and named query architecture instead of developing a query API.
I think the proposal looks really good:
<http://rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_JDOBackend>
It is my understanding that this new architecture will:
1) Make it easy to develop side-by-side implementations of the Roller
backend using JDO and JPA/EJB3.
2) Allow us to specify queries as externalized meta-data, making it
easy for database administrators to review our queries without having
Java source code access.
3) Leave our existing Hibernate impementation in-place, i.e. Craig is
not proposing that we rewrite our Hibernate implemetation using this
datamapper/named-query approach.
Craig has already started implementation, but he wants to get some
review and consensus befoe he goes much further. So please review the
proposal and respond here on the list.
I'd like to propose that Craig do this work in the sandbox of the
Roller 3.0 branch so he can keep in sync with on-going development
going on there.
- Dave
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
