ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: IgniteBinary, POJOs and indexing
Date Mon, 11 Jan 2016 11:07:19 GMT
I mean it would be quite weird if dynamically created index silently
disappears at some point. This may be obvious for you but not for everyone.
We can start with version which does not persist dynamic configuration but
looking forward it must be designed with persistence in mind. Probably we
can utilize some system cache and achieve persistence using store.

Sergi

2016-01-10 19:51 GMT+03:00 Andrey Kornev <andrewkornev@hotmail.com>:

> 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