I would do index creation/drop through custom messages in discovery. We already use this to start and stop caches and start continuous processes. This approach is much easier from synchronization standpoint. Moreover, you guarantee that altering happens on single topology version.
--Yakov 2015-06-01 17:41 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>: > Yo guys! > > I think it is time to start implementing this feature since it became > really relevant lately. > > Currently we have static indexing configuration via either > CacheConfiguration.setIndexedTypes or CacheConfiguration.setTypeMetadata. > Now we want to have IgniteCache API methods like createIndex/dropIndex > which will allow to modify index layout at runtime without cluster restart. > > I think on the public API side we have to create index description classes > like SQLSortedIndex, FulltextIndex, SQLGeospatialIndex. I personally don't > like approach with weirdly structured maps which we have in > CacheTypeMetadata, but there it was done for simpler Spring XML support. > > From the implementation standpoint I think we have to utilize replicated > transactional sys cache with continous queries to listen updates from it. > Put index description objects there and handle these updates on all the > interested nodes. > > On start each cache has to attempt load its initial index configuration > transactionally or if it already exists, then utilize runtime configuration > from cluster. > > At Indexing level we have to just find needed GridH2Table, take write lock > on it, add index, fill it with data from primary index and release the > write lock. Non-blocking approach we can implement further. > > Index drop is basically the same. > > Lets discuss API and implementation here and then I'll create jira issue > with final description. > > By the way I am a bit busy to implement this stuff myself, so anyone > interested please go ahead! > > Sergi >
