continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlos Sanchez" <car...@apache.org>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Mon, 08 Jan 2007 19:45:51 GMT
On 1/2/07, Rahul Thakur <rahul.thakur.xdev@gmail.com> wrote:
> ----- Original Message -----
> From: "Brett Porter" <brett@apache.org>
> To: <continuum-dev@maven.apache.org>
> Sent: Wednesday, January 03, 2007 4:59 PM
> Subject: Re: [discuss] iBatis, JPA and Java 5.0
>
>
> > I've been thinking stay with JDO for now, look at JPA in the long
> > term.
> >
> > I haven't used iBatis, and would be happy to hear some practical
> > experience from people who have. I tend to think of it as "a more
> > productive JDBC", as opposed to the different programming model of
> > JDO/Hibernate/JPA.
> >
>
> I haven't used it either, but that thread got me thinking about what
> would drive the choice of a persistence solution if we were rethinking
> jpox.

I did use it and yes, it's a "more productive" JDBC. If you need to do
low level stuff then go for ibatis, but I wouldn't do it for Continuum
unless really needed, it's going to be pretty verbose.

I don't thing it's a good idea to have several implementations of the
data store (JDO, ibatis, JPA,...), there's gonna be a lot of
refactoring work and one will be the default while the others won't
get a good level of stability not being widely used.

>
> > Having worked with a number of models myself on large production
> > sites (straight jdbc, castor, object structured jdbc, and now jdo2),
> > I really like the design of the jdo2 API. It does a good job of
> > giving a nice clean API that manages to keep the declarativeness
> > while still allowing good performance through fetch groups and lazy
> > loading.
> >
> > I think the store itself that we have is quite stable, but it's API
> > is too simple.
>
> Yep, it is verbose, IMHO. I am keen to explore and see if we can
> consolidate some of them by wrapping up the possible criteria in a
> 'Query' object and make the store interface leaner.
>
> >
> > I think that the way we use the store hasn't taken into consideration
> > the way that the objects are returned (ie, they may be missing some
> > fields you didn't request, etc). The way Continuum is designed means
> > you get to a certain point where you want to save an object and you
> > find that you can't, or you aren't saving everything you want, etc.
> >
>
> I am not sure what you refer to by:
> [snip]
>  The way Continuum is designed means
> > you get to a certain point where you want to save an object and you
> > find that you can't, or you aren't saving everything you want, etc.
> [/snip]
>
> Could you please give an example?
>
> > Changing to another type of store will make that worse and we'll
> > discover the same problems and have to make the same design choices
> > then. So, I'd prefer to address them first.
> >
>
> Yeah, possibly will make it worse if and when we start :-), and +1 on
> the design choices bit.
>
> > IMO, we need to centralise more of the object access. So, obviously
> > we've centralised JDO to the store, which is good. But I think you'll
> > find the use of the store itself is a little too proliferated, at
> > least for the level of abstraction you have.
> >
>
> That is what we want to try on that branch that Jesse created. I am
> hoping I can get a proof out before Jesse wraps up his changes :-)
>
> Rahul
>
> > What you ideally want to be able to do is say that a certain set of
> > actions are going to constitute the entire transaction, and do the
> > reading from the store at the start and the saving at the end
> >
> > I'm oversimplifying, but that's what I'm generally thinking. I
> > haven't looked at that code in a year and a half though - so maybe
> > it's not quite as relevant now.
> >
> > - Brett
> >
> > On 03/01/2007, at 2:43 PM, Rahul Thakur wrote:
> >
> >>
> >> These buzzwords have been making rounds on IRC and dev list :-),  and
> >> after slight digging around I found a reference to a similar
> >> discussion here:
> >> http://www.mail-archive.com/ibatis-user-java@incubator.apache.org/
> >> msg01251.html
> >>
> >> Agreed that the store implementation for Continuum should be
> >> pluggable, and if we are rethinking JPOX, then IMHO it might be
> >> worth taking into account JPA and Java 5.0.
> >>
> >> What do others think?
> >>
> >> Cheers,
> >> Rahul
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

Mime
View raw message