I propose the following API:
IgniteCahe.createIndex(Index idx);
IgniteCahe.dropIndex(String idxName);
abstract class Index {
Index(String idxName);
}
class SQLSortedIndex extends Index {
void addField(String fieldName, boolean asc);
}
class SQLGeoSpatialIndex extends Index {
SQLGeoSpatialIndex(String idxName, String fieldName)
}
class FulltextIndex extends Index {
void addField(String fieldName);
}
Sergi
2015-06-01 19:13 GMT+03:00 Sergi Vladykin <sergi.vlady...@gmail.com>:
>
> I would do index creation/drop through custom messages in discovery. We
>> already use this to start and stop caches and start continuous processes.
>>
>
> Could you please explain in more details how this works?
>
>
>> This approach is much easier from synchronization standpoint.
>
>
> I'm more familiar with cache transactions. What exactly is easier? Am I
> missing something hard in tx?
>
>
>> Moreover, you
>> guarantee that altering happens on single topology version.
>>
>
> I don't see why we need to care about it in this case.
>
> Sergi
>
>
>
>> --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
>> >
>>
>
>
