On Wed, Oct 10, 2012 at 11:27 PM, Jiri Jetmar <[email protected]> wrote:
>> The Indexing hooks into the UnitOfWork Callback mechanism, and the >> implementation is allowed to be eventually consistent. > > Ok, I take a look into the SQL EntityStore and SQLIndexing source code > and it looks > like that the Entity State changes are propagated using the > notifyChanges() call (StateChangeListener Impl). Yes, correct. > Means then when a Entity is stored in the EntityStore (using > uow.complete() ) it is immediately (and in one > transaction ?) "stored" also in the indexing schema ? It happens after the completion of the UnitOfWork, i.e. after the SQL transaction. > Or there are two > transactions, one for the > EntityStore and one for the SQLIndexing so that therefore they might > be eventually consistent ? It is allowed that the Indexing subsystem is buffering and inconsistent, for instance to batch changes for performance reasons. Of course, many applications will need better consistency in the index, so the default is "synchronous, outside transaction". >>> Q : Domain Model Versioning and/or Migration >> >> Indexing == Drop it, reindex. > > Well, this might work for smaller datasets but for large databases I > would avoid to reindex, means move data from the storage, > processes it somehow, and then write it back in another representation > that fits the indexing requirements. Well, Google kind-of does it for the entire WWW. Instead of dropping the entire dataset, they let it slowly expire upon failure to read the data in an ever running indexing cycle. It is very hard to discuss this topic in "generic terms", and I would prefer more concrete usecases, since people with a SQL background tend to rely on "query" a lot more than is necessary. When I developed a platform for "Implied Volatility Surface Calculation" at work using Qi4j, we didn't even need indexing at all... > But I think the lazy-migration approach sounds interesting - will give > it a try.. The Migration idea is fairly novel, and I haven't seen it anywhere else (info on the contrary are appreciated). When it was conceived, we expected tooling to be able to hook into refactoring tools to auto-generate the common cases (move/rename, add/remove properties/associations,..) but never had enough steam to get there. Cheers -- Niclas Hedhman, Software Developer 河南南路555弄15号1901室。 http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
