On 1/2/07, Rahul Thakur <[EMAIL PROTECTED]> wrote:
----- Original Message -----
From: "Brett Porter" <[EMAIL PROTECTED]>
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
