Can you expand on how "full history" will work ? Is it history of entity/value state (audit) or is it capture of application events (Event sourcing)? Because how pure state history can help with "data merge" ? It helps for plain text, but for entity state (invariants) ? Also I am not sure what you mean by shared common state. Isn't whole entity store final shared state?
Asynchronous "push" model seems very natural for interactive/UI parts of application, but less natural for business logic (transaction script by M.Fowler ) for me. Interesting work in area of fetch optimization is AutoFetch[1,2] and I think idea can be applied also for remote "batch" operations optimization. cheers, - Tibor [1] http://www.cs.utexas.edu/~wcook/papers/AutoFetch/autofetch.pdf [2] http://www.avaje.org/autofetch.html On Sun, May 20, 2012 at 8:31 AM, Niclas Hedhman <[email protected]> wrote: > 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 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
