You are a genius. Putting all strings together like this. Great thinking and +1
from me of course.
Such a perfect development. I was thinking about the stuff Greg talks about for a while now and found it very promising
in almost any kind of application.
And as qi4j is our sandbox / playground we now can try out how this works and
see if we run into any issues.
What we mustn't forget in the process is performance and optimization possibilities (at least think about them / point
them out).
Idempotence of operations / replay / projections of state ... Also the whole SCM (darcs, git, svn) issue where we can
learn tons of thing about this kind of working or the use of logs of changes from the financial industry (accounts) can
surely help us a lot.
What we also talked about is how this relates to versioning and retrieving older versions of our entity state (WORLD).
Or having certain changes excluded from the projected version (i.e. discarded changes from auditing) or whatever.
What there would perhaps be interesting is to get some more meta information about the UseCase at prepare. The ES may
ignore that OR use it internally for auditing (user, time, context).
What is also interesting then is to publish changes to Entities as an atom
feed. You have all the information there ...
Michael
Am 08.04.2009 3:31 Uhr, schrieb Rickard Öberg:
Hey,
If you're on the DDD Yahoo mailinglist you will have seen the
discussions about CommandQuerySeparation and EventSourcing lately.
EventSourcing is defined by MF here:
http://martinfowler.com/eaaDev/EventSourcing.html
During the persistence refactoring I realized that all our EntityState
changes can now be captured as events, and I even have an EntityState
implementation that does this. Me and Michael have also been talking
about doing event-based entitystores. When it comes to building scalable
applications that also have a need for auditing this would be extremely
convenient to have.
All this taken together I think we have a unique opportunity with Qi4j.
I think we could essentially change EntityStore.prepare() into:
prepare(EntityStoreChange)
where EntityStoreChange captures a series of EntityStateChange, each of
which contains the id, what happened, the value, and the usecase name.
Example:
"123, set property, name, Rickard, 'Update name'"
The usecase name we get for free since UnitOfWork is created with a
Usecase that has a name. We might consider removing the method that
takes a default Usecase, just to encourage always setting a name for
auditing purposes.
The EntityStore would then take the changes and apply them to the store
to get the persisted stated into a synced up position. If the events are
also stored separately this becomes a way to get read-databases synced,
to get indexes synced, to get audit logs, and other similar things. What
helps for us, compared to what MF writes about, is that the processing
is already done, so the event that comes will always have the same
effect and not require external or internal resources. It is more like
the Subversion example that he noted.
A naive implementation would store the EntityStateChanges using the full
data as indicated above. A more sophisticated version would be that the
EntityStoreChange contains the usecase name, that repeated sets of the
same property are coalesced, and that repeated updates of the same id is
done once. This can be represented in XML as:
<usecase name='Add child'>
<entity id='123'>
<setproperty name='name'>Rickard</setproperty>
<setproperty name='age'>33</setproperty>
<setassociation name='childof'>456</setproperty>
</entity>
<entity id='456'>
<addmanyassociation name='children' index='0'>123</addmanyassociation>
</entity>
</usecase>
---
Do this in binary to make it more compact on the wire. This can then be
expanded to the full format when applied.
But what about the main idea? For/against? It would make Qi4j inherently
EventSourced, and also almost trivially BASE-oriented. For my own
selfish purposes (as I need scalability + audit logs) that would be very
attractive.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
