Rickard and I had a fruitful brainstorm sessions yesterday, and I thought he would post information about the result. Anyway, we have reviewed the last round of changes in the Entity SPI, i.e. the interaction between Qi4j Runtime and Entity Stores. We have concluded that the support for migration that we were working towards are getting increasingly complex, and a simpler solution is available, but higher up in the application stack, i.e. as a Library.
How is this supposed to work? There are two parts of the solution and a pattern; 1. Command recording/playback. 2. Event recording/playback. Commands Recording of Commands are done by marking the methods with the @CommandMethod (better name) annotation, which is the marker of where the Command Recorder/Playback concern should be applied. That concern will either record (normal case) all arguments to the method on a successful exit, and pass it on to a CommandRecordingService. However, client code can set the CommandRecordingService in 'playback' mode, in which case the recorded commands will be played back into the @CommandMethod methods, and the concern will see that no recording should occur. The playback can be set to a particular starting point if needed, or the beginning of the log. Events Essentially, event record works in the same manner. During a command, the invocations occur as usual. But methods (typically on internal private mixins) marked with @EventMethod (better name?) will have a concern applied to it, same as the one for concerns. So instead of CommandRecordingService, there will be a EventRecordingService, and likewise the events can be played back by clients. In both of the above, the event log and command log needs to be using the current unitOfWork, since if the UoW is discarded the logs must be too. Now to the Pattern, Commands are methods on Entities. The commands dictates what should happen, and invokes the underlying business-logic / domain model, which may be a lot of different things. The methods that wants to 'emit' an event are marked with the @EventMethod annotation, to indicate that an important state change has occurred. The Events becomes a history log of all things that has happened in the domain model, to be reproduced later. So, the command is the 'controller' which executes any number of calls, resulting in 0..n events. The recording of commands and recording of events have different purposes. If the domain model is stable, but the commands are in fluctuation or a lot of new features are being added, then the Event recording mechanism should be used for migration purposes. However, if the commands that are being invoked are stable (perhaps an external requirement) but a lot of work is being done on the domain model, then the command recording mechanism is better for migration support. So, what are we saying? With a correct setup of Event (or Command) recording, it is possible to restore the Entity Store state. If you use the suggested event/command system, it is recommended that you consider the EntityStore a "snapshot" of the current state, and the real state is recorded as a sequence of events in the domain model. Hence, the "snapshot" may be zapped, playback the event log and you will have the EntityStore snapshot back with same values. The EventRecordingService will also provide a publishing service, so that various other systems can consume those events, such as statistics, backup, grids and what not... So what are the consequences code-wise; 1. All the stuff that was added to support migration at ES level is being removed/rolled back. No hashcodes for types, no events in signaling between UoW and EntityStore, and basically roll back to a SPI more similar to what we had before.. 2. The creation of such a library. Has not started yet, but is probably not too hard to make. 3. A subsystem to publish the event (and command) log(s) over a REST API. Rickard probably has more things to add to this. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
