On Sat, May 19, 2012 at 6:44 PM, Tibor Mlynarik <[email protected]> wrote:
> 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. As you realized, this opens a can of worms and not sure it can be sorted out. First of all, shared common state is pure evil and need to be avoided. Secondly, "batch" is a optimization abstraction and something I don't want to leak to the domain model. The question COULD then become; What-If the whole UnitOfWork abstraction is turned from a synchronous "pull" model to an asynchronous "push" model?? If that could be solved in a neat way, perhaps this whole thing becomes solvable without leaking abstractions. It also feels like a "blazing trails" way of doing persistence... Does anyone have pointer to other work in this area?? > 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. With a fast-enough store, "fetch plan" is not needed. That means that "fetch plan" is not a concern of the domain model. Hence, any exposure of "fetch plan" to domain model, is a "leaked abstraction" and that is something we strive hard to avoid. > 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. Well, we already have versioned instances, and any ES can (should) re-check that no changes has occurred to ANY of the read entities, and a concurrent modification exception will occur if it happens, and for the code to re-try... Also, keep in mind that I intend to support "full history" natively in Qi4j. And it looks like a "Git" abstraction becomes natural. This means that one could allow parallel changes happening in separate "branches" and a "data merge" needs to become a central feature... Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
