On Tue, May 22, 2012 at 5:42 AM, Tibor Mlynarik <[email protected]> wrote: > Can you expand on how "full history" will work ?
I posted some ideas a few weeks ago. 1. It should be possible to put a datetime on the UoW creation, which provides a read-only UoW on how the state was at that time. I have not spent much time thinking of the implications of "git branching" yet... 2. It should be possible to obtain a "timeseries" view on any Property, with a timestamp as the key and the property value as the value. > Is it history of entity/value state (audit) or is it capture of > application events (Event sourcing)? I don't understand the difference. Event Sourcing is a possible implementation strategy of the "history". > Because how pure state history can help with "data merge" ? It helps > for plain text, but for entity state (invariants) ? Yes, perhaps "invariant checks" are a pre-requisite for this to work at all. But ultimately, "merge" is a concept that can be applied to any (semi) structured data, just that the "merge algorithm" differs depending on structure. > Also I am not sure what you mean by shared common state. > Isn't whole entity store final shared state? I was referring to a shared state for the UnitOfWork, especially across a network. Qi4j is trying hard to minimize concurrency issues in general, but that is not the major objection here, but the whole lifecycle headaches of cross-network resource allocations, leases, security and scalability issues. > 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. Possibly correct, but that doesn't mean it is the efficient way forward. Similar statement can be made about CQRS/ES and many other innovative ways to change the "natural for business logic" status quo. > Interesting work in area of fetch optimization is AutoFetch[1,2] and I > think idea can be applied also for remote "batch" operations > optimization. I will look into that when I have some more time, maybe tonight... > [1] http://www.cs.utexas.edu/~wcook/papers/AutoFetch/autofetch.pdf > [2] http://www.avaje.org/autofetch.html 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
