Sure. thanks for the reply. I think in this case we should mention a new method in all error messages like 'cache create failed because of different configs'.
So a user can easily find a new method to apply. So product will point itself to a method how to get the evolution of cache configs without re-loading all data. ср, 21 нояб. 2018 г. в 17:05, Eduard Shangareev <eduard.shangar...@gmail.com >: > Dmitriy, > > From my point of view, it's not good to have such unexpected behavior (and > change old one) for cache and getOrCreateCache method. > It should be a conscious decision, not an accident. > > On Wed, Nov 21, 2018 at 5:01 PM Eduard Shangareev < > eshangar...@gridgain.com> > wrote: > > > Vladimir, > > > > 1) Affinity could be changed, but count of partition couldn't be. > > 2) So it would trigger 2 PME. Dynamic start and stop. > > 3) In theory, should cancel them and new setting should be applied. How > it > > works now? Create an index and stop node, for example. > > > > On Wed, Nov 21, 2018 at 4:56 PM Vladimir Ozerov <voze...@gridgain.com> > > wrote: > > > > > Hi Ed, > > > > > > Several questions from my side: > > > 1) If we do not allow to change the most demanded by users things like > > > affinity or persistence/in-memory, then what kind of configuration > > > properties do we expect to be changed? Can we have several examples? > > > 2) How will it interact with PME? > > > 3) How will it interact with CREATE INDEX and ALTER TABLE commands? > > > > > > On Wed, Nov 21, 2018 at 4:48 PM Eduard Shangareev < > > > eduard.shangar...@gmail.com> wrote: > > > > > > > Igniters, > > > > > > > > I propose new public API to change the cache configuration of > > persistent > > > > caches with keeping data. > > > > > > > > It would look like: > > > > > > > > Ignite ignite = ...; > > > > ignite.restartCaches(cfg1, ... cfgN); > > > > > > > > where cfgX is a new cache configuration, which contains the name of > an > > > > existing persistent cache. > > > > > > > > The obvious limitation: > > > > - affinity key mapping couldn't be changed; > > > > - count of partitions couldn't be changed; > > > > - MVCC couldn't be turned off/on; > > > > - persistent couldn't be turned off; > > > > - group settings couldn't be changed (group name); > > > > - if cache belongs to group it's needed to restart all of them. > > > > > > > > Failure scenario is the crucial thing (and most difficult): > > > > - initiator fail; > > > > - cluster restart at any stage; > > > > - joining/starting offline nodes. > > > > > > > > Some thoughts about implementation: > > > > - stop cache with destroy=false; > > > > - start cache dynamically with new configuration; > > > > - if indexes settings changed - remove index.bin to start indexation; > > > > - change blt-history when start cache initiated to not allow join > nodes > > > > with old configuration; > > > > - use restartId (IGNITE-8911) to not allow to start cache in between. > > > > > > > > Your thoughts? Would it be a useful feature? > > > > > > > > > > > > > -- > > Best regards, > > Eduard. > > >
