That's kind of what you discussed for the streamflow persistence architecture.
So it will be moved to qi4j, even better.
Really nice writeup.
I like it very much. What we have to keep an eye on is caching / providing snapshots because of performance penalties
when reading too many changes. So we should add a number of performance tests to assure it doesn't get out of control.
Perhaps some support from scm methodology for merging changes really fast would
be helpful.
What plans do you have on implementing that? In a local branch of your own? What about the current ES changes you just
finished, will you still provide those or are they now obsolete?
Perhaps you can / should post this to some other place (ddd-mailing list?) to get some feedback from other guys (greg
young etc) on the pros and cons of this architecture.
I like it as it makes my ChangeLogES implementation I did in September obsolete
and is of course much much better.
Could you perhaps provide a nice draw up of the big picture for people to
discuss?
Michael
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
