Hey,
The EntityStore SPI has been moving more and more towards a
BASE/EventSourcing concept, where the commit of a UnitOfWork creates an
event log rather than changes to a persistent store. This log can then
be used to update a read-store, indexes, reporting, auditing/logging, etc.
However, currently the EntityStore is responsible for both of these
things: writing the log and reading data. It might be even better to
separate these two completely, so that the read-store is on "equal
status" compared to the indexing and other log-consumers.
Basically, an EntityStore (through EntityStoreUnitOfWork) would then
ONLY be responsible for answering read-requests, i.e. getEntityState.
Writes of events would be to something else, like EntityEventStore or
similar. The EntityStore would then subscribe to events from the
EntityEventStore, as would the indexing. The transactional parts would be:
1) Storing events in the EntityEventStore
2) Getting and applying events in EntityStore/indexing
The key point is that it is crucial to know when the readstore and
indexing are "out of date" so that they can request event logs from the
EntityEventStore. Today this is not possible for the indexer, for
example: when events come in they MUST be processed and stored, and if
it fails there's no way to "catch up". The situation becomes even worse
if the indexer and event store is on different machines.
What do you think?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
