Sergi,
I see you have plain index and then sorted index. Do we even have indexes
that are not sorted in Ignite?
D.
On Thu, Jun 4, 2015 at 1:00 AM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:
> 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
> >> >
> >>
> >
> >
>
