Re: DataMapper/named-queries proposal for JDO and JPA support

[Craig L Russell <Cr...@Sun.COM>]

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.

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

Thanks for the feedback,

Craig
>
> -- Allen
>
>
> Dave Johnson wrote:
>> Adding Craig to the CC list.
>> - Dave
>> On 6/29/06, Dave Johnson <sn...@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!

Re: DataMapper/named-queries proposal for JDO and JPA support

[martin nilsson <ve...@gmail.com>]

I think I understand why the Manager classes is not enough for an
abstraction. It is pretty clear when you look at some some of the rolller
code right now. Lot of business code that needs to be copied to every new
persistance implementaion. But why not use the DAO pattern?
I would suggest to have Managerclasses that are concerned with business
logic and Dao classes that are concerned whith persistance. Then it would be
interfaces like UserManager and UserDao.
And implementations like UserJPADao, UserHibernateDao etc.
In Craigs strategy there is contract between the business logic and
persistance layer that I don like. And that is the named query which is also
a runtime dependency. Let the persistance layer choose if the DBA wants to
tweak the SQL.



On 7/13/06, Allen Gilliland <al...@sun.com> wrote:
>
> more comments ...
>
>
> Dave Johnson wrote:
> > Comments below...
> >
> >
> > On 7/12/06, Allen Gilliland <al...@sun.com> wrote:
> >> I don't think that answers my original question.  Why do we need both
> >> jdo and jpa?  What is the connection between the two?
> >
> > JDO and JPA are both persistence APIs and for each there are multiple
> > implemetations. For JDO, there's Kodo and JPOX and others. For JPA,
> > there's Hibernate JPA, OpenJPA and Glassfish JPA.  Using the Data
> > Mapper design, we'd be able to test a very wide range of persistence
> > libraries.
>
> got it.  thanks.
>
>
> >
> >
> >> 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.
> >
> > Been there, done that and don't want to do it again. I think we all
> > agree that supporting multiple persistence libraries makes no sense.
> > The goal should be to pick one and only one.
>
> exactly.  you will find me a very grumpy and bastardly person if you try
> and suggest that you want to commit all these various backends into
> Roller.  i am already weary of simply swapping one backend for another.
>
>
> >
> >
> >> 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.
> >
> > JPA is the persistence API used by EJB3. Craig killing three birds
> > with one stone here.
>
> cool.  then why are we talking about doing jdo?  sorry, i don't keep up
> with all these persistence apis as much as i should, but i don't see the
> benefit of continually swapping them around.
>
>
> >
> >
> >> 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.
> >
> > That's what we're doing now.
> >
> > The reason Craig is doing this work is to help the Roller community
> > figure out the best way to remove our dependence on LGPL components
> > and choose the best persistence architecture.
>
> i see.
>
>
> >
> >
> >> 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.
> >
> > Hibernate's LGPL license is not acceptible for an Apache proiect.
> > Plus, I'd much prefer that Roller depend on a standard persistence
> > API, than on one vendor specific implementation.
>
> personally i don't consider either of those real incentives to change
> the backend, but that's coming from a customers point of view.  since
> Hibernate works fine and I don't have any legal problems with using it
> then its way more trouble to worry about switching it than it is to just
> leave it as far as i'm concerned.
>
> for folks who run large Roller installations it is a very big and
> troubling change to swap out an entire backend strategy, so it's not
> something that i look forward to at all.  and at the end of the day
> making that change does not provide a single benefit for existing users.
>   i guarantee that most roller users could care less about the
> apache/hibernate licensing issue and whether or not roller user
> hibernate vs. jpa.
>
>
> >
> >
> >> >> 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?
> >
> > That's a good point. The main reason for the DataMapper abstraction is
> > to allow mutliple implementations to co-exist, but it has a couple of
> > side-benefits:
> >
> > - Queries are externalized and maintained in one location, so that a
> > DBA can examine and even tweak them without modifying source code.
>
> umm, what queries?  all of our queries are handled by our ORM solution.
>
> plus, you can externalize your queries with or without this data mapper,
> so it's not like that's a unique feature that the data mapper adds.
>
>
> >
> > - Separation of concerns is generally a good thing and the data mapper
> > approach separates the business/applicaiton logic from the persistence
> > logic.
>
> but, that's what the manager interfaces already do.  they separate
> business logic like getWeblogEntries(x, y, z) from persistence logic
> like "select * from weblogentry ...".
>
> the data mapper is really just another sublayer of abstraction which i
> said i didn't see the benefit of.  maybe if i could see a more flushed
> out proposal for how this data mapper will work then i'll understand it
> better.
>
>
> >
> >
> >> 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.
> >
> > I don't think data mapper is a waste of time because a) we'll learn a
> > lot by comparing JPA and JDO implementations, b) JDO and JPA are
> > similar enough to make the data mapper approach feasible and c) the
> > Data Mapper architecture is essentially good has some other benefits.
>
> I don't understand, you said above that ... "the goal is to pick one and
> only one."
>
> So why would we design our code to add extra complexity which allows us
> to more easily support multiple implementations if we don't even want
> multiple implementations?  what do we learn by comparing various
> implementations?  why go to that effort?  even if jdo and jpa are
> similar enough that this data mapper will help, why spend the time to
> develop both when we know we are only going to use one of them?
>
> i am certainly confused about what our direction is with this new
> backend work.  i don't understand why we aren't just picking a single
> approach/tool and using that, whether it's jdo or jpa or something else.
>
> -- Allen
>
>
> >
> > - Dave
>

Re: DataMapper/named-queries proposal for JDO and JPA support

[Allen Gilliland <al...@sun.com>]

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

Re: DataMapper/named-queries proposal for JDO and JPA support

[Anil Gangolli <an...@busybuddha.org>]

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. 

Re: DataMapper/named-queries proposal for JDO and JPA support

[Allen Gilliland <al...@sun.com>]

more comments ...


Dave Johnson wrote:
> Comments below...
> 
> 
> On 7/12/06, Allen Gilliland <al...@sun.com> wrote:
>> I don't think that answers my original question.  Why do we need both
>> jdo and jpa?  What is the connection between the two?
> 
> JDO and JPA are both persistence APIs and for each there are multiple
> implemetations. For JDO, there's Kodo and JPOX and others. For JPA,
> there's Hibernate JPA, OpenJPA and Glassfish JPA.  Using the Data
> Mapper design, we'd be able to test a very wide range of persistence
> libraries.

got it.  thanks.


> 
> 
>> 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.
> 
> Been there, done that and don't want to do it again. I think we all
> agree that supporting multiple persistence libraries makes no sense.
> The goal should be to pick one and only one.

exactly.  you will find me a very grumpy and bastardly person if you try 
and suggest that you want to commit all these various backends into 
Roller.  i am already weary of simply swapping one backend for another.


> 
> 
>> 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.
> 
> JPA is the persistence API used by EJB3. Craig killing three birds
> with one stone here.

cool.  then why are we talking about doing jdo?  sorry, i don't keep up 
with all these persistence apis as much as i should, but i don't see the 
benefit of continually swapping them around.


> 
> 
>> 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.
> 
> That's what we're doing now.
> 
> The reason Craig is doing this work is to help the Roller community
> figure out the best way to remove our dependence on LGPL components
> and choose the best persistence architecture.

i see.


> 
> 
>> 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.
> 
> Hibernate's LGPL license is not acceptible for an Apache proiect.
> Plus, I'd much prefer that Roller depend on a standard persistence
> API, than on one vendor specific implementation.

personally i don't consider either of those real incentives to change 
the backend, but that's coming from a customers point of view.  since 
Hibernate works fine and I don't have any legal problems with using it 
then its way more trouble to worry about switching it than it is to just 
leave it as far as i'm concerned.

for folks who run large Roller installations it is a very big and 
troubling change to swap out an entire backend strategy, so it's not 
something that i look forward to at all.  and at the end of the day 
making that change does not provide a single benefit for existing users. 
  i guarantee that most roller users could care less about the 
apache/hibernate licensing issue and whether or not roller user 
hibernate vs. jpa.


> 
> 
>> >> 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?
> 
> That's a good point. The main reason for the DataMapper abstraction is
> to allow mutliple implementations to co-exist, but it has a couple of
> side-benefits:
> 
> - Queries are externalized and maintained in one location, so that a
> DBA can examine and even tweak them without modifying source code.

umm, what queries?  all of our queries are handled by our ORM solution.

plus, you can externalize your queries with or without this data mapper, 
so it's not like that's a unique feature that the data mapper adds.


> 
> - Separation of concerns is generally a good thing and the data mapper
> approach separates the business/applicaiton logic from the persistence
> logic.

but, that's what the manager interfaces already do.  they separate 
business logic like getWeblogEntries(x, y, z) from persistence logic 
like "select * from weblogentry ...".

the data mapper is really just another sublayer of abstraction which i 
said i didn't see the benefit of.  maybe if i could see a more flushed 
out proposal for how this data mapper will work then i'll understand it 
better.


> 
> 
>> 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.
> 
> I don't think data mapper is a waste of time because a) we'll learn a
> lot by comparing JPA and JDO implementations, b) JDO and JPA are
> similar enough to make the data mapper approach feasible and c) the
> Data Mapper architecture is essentially good has some other benefits.

I don't understand, you said above that ... "the goal is to pick one and 
only one."

So why would we design our code to add extra complexity which allows us 
to more easily support multiple implementations if we don't even want 
multiple implementations?  what do we learn by comparing various 
implementations?  why go to that effort?  even if jdo and jpa are 
similar enough that this data mapper will help, why spend the time to 
develop both when we know we are only going to use one of them?

i am certainly confused about what our direction is with this new 
backend work.  i don't understand why we aren't just picking a single 
approach/tool and using that, whether it's jdo or jpa or something else.

-- Allen


> 
> - Dave

Re: DataMapper/named-queries proposal for JDO and JPA support

[Dave Johnson <sn...@gmail.com>]

Comments below...


On 7/12/06, Allen Gilliland <al...@sun.com> wrote:
> I don't think that answers my original question.  Why do we need both
> jdo and jpa?  What is the connection between the two?

JDO and JPA are both persistence APIs and for each there are multiple
implemetations. For JDO, there's Kodo and JPOX and others. For JPA,
there's Hibernate JPA, OpenJPA and Glassfish JPA.  Using the Data
Mapper design, we'd be able to test a very wide range of persistence
libraries.


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

Been there, done that and don't want to do it again. I think we all
agree that supporting multiple persistence libraries makes no sense.
The goal should be to pick one and only one.


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

JPA is the persistence API used by EJB3. Craig killing three birds
with one stone here.


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

That's what we're doing now.

The reason Craig is doing this work is to help the Roller community
figure out the best way to remove our dependence on LGPL components
and choose the best persistence architecture.


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

Hibernate's LGPL license is not acceptible for an Apache proiect.
Plus, I'd much prefer that Roller depend on a standard persistence
API, than on one vendor specific implementation.


> >> 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?

That's a good point. The main reason for the DataMapper abstraction is
to allow mutliple implementations to co-exist, but it has a couple of
side-benefits:

- Queries are externalized and maintained in one location, so that a
DBA can examine and even tweak them without modifying source code.

- Separation of concerns is generally a good thing and the data mapper
approach separates the business/applicaiton logic from the persistence
logic.


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

I don't think data mapper is a waste of time because a) we'll learn a
lot by comparing JPA and JDO implementations, b) JDO and JPA are
similar enough to make the data mapper approach feasible and c) the
Data Mapper architecture is essentially good has some other benefits.

- Dave

Re: DataMapper/named-queries proposal for JDO and JPA support

[Allen Gilliland <al...@sun.com>]

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 <sn...@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!
>