@Tobias It's mostly about deferring loading and updating up to a certain point.
I also thought about having another JDBC EntityStore that uses a simple kind of mapping to persist the entities. With ibatis you have to do a lot upfront statement writing before it is usable. But then the question is about reinventing the wheel and rather supporting one of the existing ORM approaches (which will be tricky as well as there are no pojos but just EntityComposite interfaces). @Assoc Regarding the Associations. Do I as the EntityStore have the obligation to check for the existence of the referrered Entities and keep them up to date or fail if they don't exist (or even create them on demand) ? And what about containment by value (cascading delete) vs. containment by reference? Are normal EntityComposite properties for the former and all assoc for the latter? By now I implemented EntityComposite propertys as embedded columns of the Entity. Ibatis does not really well support multiple statements within one xml-statement declaration. So there would have to be separate crud statements for each referred to entity. Michael Tobias Ivarsson schrieb: > Hi, > I just wanted to let you know that I think it's great that someone > else is working on the same problems that I have been/am working with. > > It will be interesting to see what kind of requirements you run into > with having two different implementations towards ibatis. > > I hope it turns our great! > Happy hacking! > /Tobias > > On Wed, Jun 11, 2008 at 9:49 AM, Michael Hunger <[EMAIL PROTECTED]> wrote: >> I started doing the ManyAssoc thing for ibatis. Reading works by now >> although the effort on the ibatis side has >> increased. I had problems differentiating the AssociationTypes (Assoc, Many, >> Set, List) when having the >> AssociationModels available. Right now I reverted to >> ManyAssociation.class.isAssignableFrom(assocModel.getAccessor().getReturnType()) >> but thats quite ugly. Is this >> information available someway else? >> >> I'm currently thinking about the write/update step. If I get the changed >> entities from the uow, is there a way to >> determine which ManyAssocation entries have changed or do I have to do the >> bookkeeping myself in the EntityState? >> >> As like for neo4j it would be possible to have two versions of the entity >> store one that reads the entity fully on >> newEntityState. Another one could just return an empty hull for the >> entitystate and read the data on demand. There is a >> continuum between these. For instance the normal properties and associations >> could be read ahead and only the ManyAssoc >> resolved later. >> >> Michael >> >> _______________________________________________ >> qi4j-dev mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/qi4j-dev >> > > > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
