continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Thakur" <rahul.thakur.x...@gmail.com>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Wed, 03 Jan 2007 05:29:25 GMT
----- 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.

> 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 


Mime
View raw message