ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: IgniteBinary, POJOs and indexing
Date Sun, 10 Jan 2016 16:51:30 GMT
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.vladykin@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 <dsetrakyan@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 <andrewkornev@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
> > >
> >
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message