phil vd wrote:
One question is :if your model data is the result of applying a queue of
commands, how do you want to store it? When you think about model migration,
storing all events since the beginning looks efficient since you only have
to modify the command's code (and BTW you get a historic model for the same
price) and replay everything.

One difference between Prevayler and what we are suggesting here, is that in Qi4j there will both be the event log and the persistent store, so there is no O(size) cost with making a snapshot, or rather you don't really need to make a snapshot at all since the model is always persisted anyway.

When you apply a command, you probably need to know the last value of other
entities, supposedly stored in some kind of snapshot. So when you think
about efficiency, you need direct access to the last value, the snapshot.

Now, what about an "entityStore" containing a queue of events mapped to an
entity identity ? What about calculating the actual model's value "on the
fly" applying only a specific queue of commands (BTW commands must obviously
be deterministic). You actually extract a reverse tree of commands to apply
to get the final entity value. The snapshot is only an "optimisation" or a
cache of the last entity calculation. When you want to migrate your
commands, you simply clear the cache, you don't replay anything "in
advance".

That is one way to do it, and the correction I would make is to be precise in saying that we want to store and replay events rather than commands. A command could be "add Comment to Blog xyz" which would lead to the event "Comment with id 123 was added to Blog xyz at 2009-10-12 12:31:05 by SomeUser", i.e. it has more context to it which is needed for deterministic playback.

One problem I had with Prevayler is "snapshot generation". It takes a lot of
resources (O(model's value size)). I partly solved it by partitioning my
model in smaller snapshots. But I still had a problem with "dead" old
data... like last year "order lines", they were still present in the
snapshot ! So I had to remove "old values", and it was a mess.

This goes away in Qi4j since the model is always persistent through the EntityStore anyway.

This seems to be solved here, I can let complete branches of the "reverse
tree of commands" go to sleep gracefully because I will never traverse those
branches anymore. The added value here is that I could still migrate those
"dead data" to a new version of commands since I will only reapply those
commands when I really need to 'calculate' the latest value of my model's
entities...

Anyone still following me ?

Yup :-) Makes sense.

I will try to resume.
If you think of an entity as a result of the application of a queue of
commands using other entities you should be able to create a historical
representation of your complete model on the fly, the snapshot.

-> "queue of events"...

But if you don't consider the snapshot as a whole, but as a map of entity
values, you should be able to find out the entity last value by replaying a
smaller queue of commands (and cache it for future use).

Is it clearer or helpful ?

Yes, it is. And something like that is what we're going for. We haven't thought in terms of one log per entity identity (or one per aggregate root more likely), but that is certainly a possible implementation strategy.

/Rickard


_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to