roller-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "martin nilsson" <vegfore...@gmail.com>
Subject Re: DataMapper/named-queries proposal for JDO and JPA support
Date Thu, 13 Jul 2006 12:48:08 GMT
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 <allen.gilliland@sun.com> wrote:
>
> more comments ...
>
>
> Dave Johnson wrote:
> > Comments below...
> >
> >
> > On 7/12/06, Allen Gilliland <allen.gilliland@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message