On Jan 9, 2012, at 3:26 AM, Rickard Öberg wrote: > 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.
In my attempt to implement entity store ( OrientDB), I have optimistic locking handled by db, with ConcurrentModificationCheckConcern turned off. So I was getting out of sync with index on every concurrent modification exception. (btw, is NeoES missing this concern on purpose ?) > >> 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. I see advantage of this design. I just still have in memory FoxPro REINDEX command . Neo4j not good at storing deep entities ? I have thought that graph db is best match for complex domain models. Maybe I don't understand what you mean by multilevel values. Do you think it should be possible/easy to translate specs to Cypher using your neo-cypher-dsl ? > > 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. Thanks, -Tibor _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
