On Wed, Jul 22, 2009 at 16:36, Niclas Hedhman<[email protected]> wrote: > 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.
Would the command handler knows that it's being invoked in "replaying" context? E.g. if part of the business logic is to send sms notification for example. We don't want to invoke that sms notification routine during replay. Same question applies to event. > Commands are methods on Entities. Entity can be created and deleted. If command are methods on entities. Who will handle the "creational" command? > 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. As long as we don't deal with "remote" service? Can replay be orchestrated with remote qi4j application? This is probably a non-concern atm. Regards, Edward Yakop _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
