Sergi, Thanks for your reply.
I didn't quite get the point about the "persistent configuration storage". Could you please elaborate? >From my point of view, dynamic index management requires something similar to >the SQL DDL, like create/drop index, alter index, etc. So in addition to the >indexing metadata in the cache config, Ignite could provide an index >management API: create, drop, alter, describe. It would be up to the user to >ensure that the indexes get recreated after the cluster is restarted. Such approach is no different from the way Ignite currently handles dynamically created caches -- there is no "persistent configuration storage" to store the dynamic cache configs, and Ignite doesn't even try to recreate them after a full cluster restart -- it's the use who does that, either in the code or thru the configuration files. Thanks Andrey > From: sergi.vlady...@gmail.com > Date: Sat, 9 Jan 2016 13:10:13 +0300 > Subject: Re: IgniteBinary, POJOs and indexing > To: dev@ignite.apache.org > > I don't think we can easily implement this feature. Because it means that > we need some kind of "persistent configuration storage", which will be > consistent in all the scenarios of failures/restarts. So we have to design > this thing first keeping in mind that in the future we will store there not > only "dynamic indexes" but some other dynamic configuration as well. > > I don't think I will be able to work on it myself but since it is going to > be a general mechanism mostly unrelated to SQL we can ask someone else to > pick it up. > > Sergi > > > 2016-01-08 21:20 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > Hi Andrey, > > > > The answer right now is simple. Yes, you can create classes and add fields > > at runtime. No, you cannot change indexes that you have created in cache > > configuration. > > > > However, you are raising a very valid point. We should be able to create > > and update indexes dynamically. There is a ticket, IGNITE-735 [1], that > > has been sitting around for a while. I think we should reprioritize it. > > > > Sergi, can you please comment on how hard this would be to implement? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-735 > > > > On Fri, Jan 8, 2016 at 9:02 AM, Andrey Kornev <andrewkor...@hotmail.com> > > wrote: > > > > > Hello, Ignite Community, > > > > > > IgniteBinary javadocs mention the ability to dynamically change the > > > structure of the "classes" without restarting the cluster. The javadocs > > > even say that the new fields become automatically available to the SQL > > > queries with no extra effort. It's all fine and dandy, but how can I tell > > > Ignite that some of the new fields should also be indexed? > > > > > > Using the example from the same javadocs, my binary object initially has > > > two field A and B. I configure the cache entry metadata to index the > > field > > > A and then create the cache. When later I change the structure by adding > > a > > > new field C, how can I tell Ignite that I now want only fields B and C to > > > be included in the index? > > > > > > Related to above, is there any way to modify the indexes after the cache > > > has been started? In this case I do not modify the structure of the > > class, > > > but rather change which fields get indexed, the sorting properties, etc. > > > > > > Finally, how about introducing new POJO classes at runtime (yes, I can do > > > it -- I run in OSGi environment)? For example, at the cache creation time > > > the cache metadata only had the POJOA class annotated to index its field > > > "foo", and then later the user introduces a new POJOB class annotated to > > > index its field "bar". Would POJOB start getting indexed automatically, > > or > > > the user will be given the finger? > > > > > > Any input will be very much appreciated! > > > Andrey > > > > >
