It is a long time ago. But I think I was thinking a lot about how Greg Young explained how he does persistence only with an EventStore.
From that should follow that events should be delayed until complete(), yet be visible within the UoW thread. It could also be that I would like to see a more advanced Event system in general, which can be used for all kinds of things, not only storage. (Think ZeroMQ) And in that, there are also some transactional aspects that should be considered, similar to how hazelcast updates/events are delayed until commit. It is a large and fairly complex matter, so I am not sure we should engage in it with so little resources available. I suggest to move it out of 2.0 scope. -- Niclas On Fri, Nov 16, 2012 at 8:34 PM, Paul Merlin (Commented) (JIRA) <[email protected]> wrote: > > [ > http://team.ops4j.org/browse/QI-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18175#comment-18175 > ] > > Paul Merlin commented on QI-280: > -------------------------------- > > Gang, > > This issue is in the 2.0 jira roadmap and I would like to start discussing it. > > First, some links to related mailing-list threads: > > CommandQuerySeparation, EventSourcing and persistence (April 2009) > http://www.mail-archive.com/[email protected]/msg03109.html > > EventSourcing and UoW completion sequence (February 2011) > http://www.mail-archive.com/[email protected]/msg05975.html > > Aside from that, in the SDK we have the eventsourcing library, the > eventsourcing-jdbm EventStore implementation and eventsourcing-rest that > expose event streams as Atom using Restlet. Writing new EventStore > implementations seems pretty easy. The unit tests are far from complete and > need some love. The documentation is quite simply missing. > > Niclas, when you said _"I think we need to treat Event Store as first-class > citizen in Qi4j, just like Entity Store, with full integration into the > UnitOfWork."_ was it to solve the issue spotted in the email at the second > link or something more? > > I naïvely tried to move the call to UoWCallback.beforeCompletion() from > before applyChanges() to between applyChanges() and commit() as Rickard > suggested. The whole SDK tests pass including ones involving UoWCallbacks. > But on the other hand eventsourcing tests are pretty limited. What was your > concern about not moving this call apart from renaming the applyChanges > method? > > /Paul > > > >> EventStore >> ---------- >> >> Key: QI-280 >> URL: http://team.ops4j.org/browse/QI-280 >> Project: Qi4j >> Issue Type: New Feature >> Components: SPI >> Reporter: Niclas Hedhman >> Fix For: 2.0 - Reductionism >> >> >> Eventstore API/SPI and backend for storing events for EventSourcing. >> Currently StreamFlow one is based on JDBM, which works, but is not optimal >> perhaps > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > http://team.ops4j.org/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- Niclas Hedhman, Software Developer 河南南路555弄15号1901室。 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
