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 <[email protected]>: > 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 <[email protected]> > 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 > > >
