Mailing-List: contact roller-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: roller-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Wed, 12 Jul 2006 12:38:29 -0700
From: Allen Gilliland <allen.gilliland@sun.com>
Subject: Re: DataMapper/named-queries proposal for JDO and JPA support
In-reply-to: <46F02797-A63F-446D-8587-3DF6642BF99C@Sun.COM>
Sender: Allen.T.Gilliland@sun.com
To: roller-dev@incubator.apache.org
Message-id: <44B54FB5.7080103@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <8fb9ac720606290511g52029fefge20e983e4812d6ab@mail.gmail.com>
 <8fb9ac720606290641m4cdb2107k5f98a06c67413dbe@mail.gmail.com>
 <44A5711C.1020703@sun.com> <46F02797-A63F-446D-8587-3DF6642BF99C@Sun.COM>
User-Agent: Thunderbird 1.5 (X11/20060113)

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 <snoopdave@gmail.com> 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>