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