The observation that queries operates on "anything" is actually not that strange. An Entity could be expressed as an Identity with an associated Value object (and such notion opens interesting possibilities for "keep history")
Need to revisit when I am not tired. On Thu, Jun 23, 2011 at 10:06 AM, Rickard Öberg <[email protected]> wrote: > 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 > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
