Ok, so it's not really the same kind of approach as I did with the NeoEntityStore. Still interesting though :)
On Wed, Jun 11, 2008 at 10:32 AM, Michael Hunger <[EMAIL PROTECTED]> wrote: > @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 > -- Tobias Ivarsson <[EMAIL PROTECTED]> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
