On 6/23/11 1:25 , Niclas Hedhman wrote:
One part of the issue is that the EventStore needs to be part of the
UnitOfWork scoping and commit.
Yes! So, like we talked about before we need to look at the hooks in
before/after commit, and the semantics of that.
Not trivial I think.
I happen to get my event emits to be transacted by Hazelcast (almost
by accident), from the fact that the Command objects from a Hz queue
are wrapped in Hz transaction to survive JVM and HW failures, and
events can only be emitted as part of commands, and state manipulation
in EntityStore happens to be wrapped in the same Hz Transaction... But
that is too much of 'coincidence' for my liking.
The main semantics change for the UoW-commit sequence, if memory serves
me, is that the first round should only do a validation check, and the
second one should do the storing. With that the events can be stored as
part of the validation check, and so if it fails can unroll the state
storing. If the event storing succeeds, but the state storing fails,
this can be detected on restart.
Yes. I wasn't saying that the index/query is part of the store, but as
usual the indexer needs to interact with the store mechanism, and we
should formalize any differences between event store and entity store.
For instance, I feel that the 'range query' concept is so hard core,
that it deserves special treatment for performance reasons. So, I
would like to see an SPI being formed around that as well (or
extending existing Query Expression API/SPI system).
As I was refactoring the Query API/SPI I realized that it's actually not
specific to entities, but composites. There are even tests that are
performed on an Iterable of Transients. So, the where-clause becomes:
queryBuilder.where(Specification<Composite>)
and so the query can be done on an iterable:
queryBuilder.newQuery(Iterable)
where the iterable is backed by an event-store. If we make it possible
to plug in a finder for events, just like we can plug in a finder for a
UoW, then that's all that is needed.
As for custom operators that are highly specific, I've already thought
about that as well. Basically, with the new API, since all that is
required is "Specification<Composite" you could add custom operators
quite easily. For Sesame you might want things like:
SesameExpressions.isLiteral(Property)
that can be interpreted by the RDF EntityFinder appropriately.
Other finder-specific operators can be done the same way, without
requiring all finders to support all operators. Since they are part of a
specific static class (SesameExpressions in this case), it is clear that
require a specific finder.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
