On Sat, May 19, 2012 at 5:32 AM, Niclas Hedhman <[email protected]> wrote: > On Sat, May 19, 2012 at 7:36 AM, Tibor Mlynarik > <[email protected]> wrote: > >> your proposed load() is probably what merge() does in JPA. >> Or should load be allowed only on empty uow ? > > I doubt that it is merge(), since JPA can not operate without a backing store. > > UoW.save() --> All created, read and modified entities that are inside > the UoW, will be serialized together with other internal UoW state > into a byte stream. > > UoW.load() --> Re-establish the above byte stream into a UoW, with or > without an Entity Store. > > That means that on the server, you can traverse some entity graph, > serialize it over to the client, read the entities there as if the UoW > was still connected. (Well, then the question arises, should the > opposite then work as well?)
I see load/save functionality as enabler for remoting. But from api I would prefer this transparent usage. Remote client is assembled with RemoteEntityStore. Peer for this entity store is server side UnitOfWork. On remote uow some kind of support for batching will be needed. But here I see analogy with server side support for fetch plan. If entity store operates in-process ( i.e. jdbm, neo4j), missing support for fetch plan is not so visible. I think fetch plan is just entity store optimalisation feature, not sure what you mean by leaked abstraction. What I meant by similiarity with jpa merge was that if opposite load into serverside uow should work. It have to handle merging into its current state. And here nightmare comes. - Tibor _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
