continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: [discuss] iBatis, JPA and Java 5.0
Date Wed, 03 Jan 2007 04:15:15 GMT
Sorry, I was writing my post when this came in.  I'm in general 
agreement, and while I do think moving to something more than JDO is 
important, Brett is right, the use of hte store could use a good audit 
and re-factor.  Probably some of the problems of strange access 
approaches used currently could be identified with adding some unit 
tests that expand the current assumptions of the model. These would then 
provide some good regression tests for the eventual move to something 
more robust.

Also, I really like modello, but don't know if there are plans/schedules 
around its support for other forms of persistence than JDO.  (Though if 
we went with JPA and annotated the model, we could go the other way, 
generating all the other artifacts from the code.)


Brett Porter wrote:
> 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.
> 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.
> 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.
> 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.
> 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.
> 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


*christian** gruber + process coach and architect*

*Israfil Consulting Services Corporation*

*email** + bus 905.640.1119 + mob 416.998.6023*

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