2012/1/7 Tibor Mlynarik <[email protected]>: >> If "store" fails, then index will not happen. > > Is code in StateChangeNotificationConcern#applyChanges handling this > behaviour ? > Becouse I see there that index is commited before data.
The basic idea is that there are two reasons the UoW may not commit: application level issues like optimistic locking, or system failure. The setup should be able to handle application level failures, but not necessarily system level failures, as those would be very rare. > Some db engines behind EntityStore ( i.e. MongoDB, Neo4j ) has 'native' > support for indexes. > Is it against some Qi4j principles to have Index service backed by the same > db engine ? > (Becouse in my case, I have to. We don't own data and external updates will > not update index then.) > To implements this, it requires translate Specifications graph into engine > native query language, that's it , right ? If an underlying database can support both index and data store, that is perfectly fine. And yes, it mainly involves translating specs into the native query language. One of the main reasons we want it to be possible to separate is that most stores are good at either, but not both. Lucene is good for free text searching, but not necessarily data storage. Neo4j is great at graph queries, but not at storing deep entities (i.e. entities that use a lot of multilevel values). Being able to mix and match persistence technologies is very important if you want to be able to support different ways of accessing your data. For making it easier to keep things in sync, one idea is to use EventSourcing as the "true source", and then both data and indexing becomes caches, effectively. If a system failure happens, a rerun of the last few events will ensure that both data and index is up to date. /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
