Alexey You're right. Of course I meant growth of caches number.
I see a few points here: 1. If a grid used by various applications the cache names may overlap (like "accounts") and the application needs to use prefixed names and etc. 2. For clear or destory caches I need to know their names (or iterate over caches but I'm not sure that it is supported by API). For destroy/clear caches belonging to same group we will do it by single operation without knowledge of cache names. 3. Cache group can have cache attributes which will be inherited by a cache created in that group (like eviction policy or cache mode). 4. No reason to add specific feature like SqlShema if it applicable for regular caches as well. On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <akuznet...@gridgain.com> wrote: > Sergey, I belive you mean "increase" instead of "reduce"? > > How grouping will help? > To do some operation, for example, clear on group of cashes at once? > > 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <skoz...@gridgain.com> > написал: > > > I mean not only SQL features for caches. Single type per cache definitely > > reduces number of caches for regular user and grouping caches will help > to > > manage caches in grid. > > > > On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin < > sergi.vlady...@gmail.com> > > wrote: > > > > > I'm aware of this issue. My plan was to allow setting the same schema > > name > > > to different caches using CacheConfiguration.setSqlSchema(...). This > way > > > we > > > will have separate caches but from SQL point of view respective tables > > will > > > reside in the same schema. No need to introduce new concepts. > > > > > > Sergi > > > > > > > > > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skoz...@gridgain.com>: > > > > > > > HI > > > > > > > > Due to approach to disable to store more than one type per cache the > > > cache > > > > use becomes similar the table use for databases. > > > > So I suppose would be good to introduce a database/schema-similar > > concept > > > > for caches. It may be implemented as a non-default behavior for > > backward > > > > compatibility. > > > > > > > > On Sat, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan < > > dsetrak...@apache.org > > > > > > > > wrote: > > > > > > > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov < > > > > akuznet...@gridgain.com> > > > > > wrote: > > > > > > > > > > > I remember couple more thing for 2.0 > > > > > > > > > > > > How about to drop **ignite-scalar** module in Ignite 2.0? > > > > > > > > > > > > > > > > Why? > > > > > > > > > > > > > > > > And may be drop **ignite-spark-2.10** module support as of > > **Spark** > > > 2 > > > > is > > > > > > on **scala 2.11**. > > > > > > > > > > > > > > > > I would drop it only if it is difficult to support. Do we know what > > > kind > > > > of > > > > > impact will it have on the community? Anyone is still using 2.10? > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda < > dma...@gridgain.com> > > > > > wrote: > > > > > > > > > > > > > Let’s add this [1] issue to the list because it requires > > > significant > > > > > work > > > > > > > on the side of metrics SPI. > > > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3495 < > > > > > > > https://issues.apache.org/jira/browse/IGNITE-3495> > > > > > > > > > > > > > > — > > > > > > > Denis > > > > > > > > > > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov < > > yzhda...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > > > > Not yet. The thing is that our recent experience showed that > it > > > was > > > > > not > > > > > > > > very good idea to go with caches. E.g. when you try to > > > deserialize > > > > > > inside > > > > > > > > continuous query listener on client side it implicitly calls > > > > > > cache.get() > > > > > > > > which in turn may cause deadlock under some circumstances. > > > > > > > > > > > > > > > > --Yakov > > > > > > > > > > > > > > > > 2016-08-02 2:41 GMT+03:00 Dmitriy Setrakyan < > > > dsetrak...@apache.org > > > > >: > > > > > > > > > > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov < > > > > yzhda...@apache.org> > > > > > > > wrote: > > > > > > > >> > > > > > > > >>> One more point. > > > > > > > >>> > > > > > > > >>> I insist on stop using marshaller and meta caches but > switch > > to > > > > > > > spreading > > > > > > > >>> this info via custom discovery events. > > > > > > > >>> > > > > > > > >> > > > > > > > >> Do we have a ticket explaining why this needs to be done? > > > > > > > >> > > > > > > > >> > > > > > > > >>> > > > > > > > >>> --Yakov > > > > > > > >>> > > > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan < > > > > > dsetrak...@apache.org > > > > > > >: > > > > > > > >>> > > > > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < > > > > > > yzhda...@apache.org> > > > > > > > >>>> wrote: > > > > > > > >>>> > > > > > > > >>>>> Guys, I think we can also split event notification for > user > > > > > > listeners > > > > > > > >>> and > > > > > > > >>>>> internal system listeners. I have been seeing a lot of > > issues > > > > > > caused > > > > > > > >> by > > > > > > > >>>>> some heavy or blocking operations in user-defined > > listeners. > > > > This > > > > > > may > > > > > > > >>>> block > > > > > > > >>>>> internal component notification (e.g. on discovery event) > > > > causing > > > > > > > >>>> topology > > > > > > > >>>>> hangings. > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > >>>> Sure. There are a lot of features being added. Would be > nice > > > to > > > > > > assign > > > > > > > >> a > > > > > > > >>>> release manager for Ignite 2.0 and document all the > > discussed > > > > > > features > > > > > > > >> on > > > > > > > >>>> the Wiki. > > > > > > > >>>> > > > > > > > >>>> > > > > > > > >>>>> > > > > > > > >>>>> --Yakov > > > > > > > >>>>> > > > > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey Goncharuk < > > > > > > > >> alexey.goncha...@gmail.com > > > > > > > >>>> : > > > > > > > >>>>> > > > > > > > >>>>>> Folks, > > > > > > > >>>>>> > > > > > > > >>>>>> Recently I have seen a couple of emails suggesting > > > > > > > >> tasks/improvements > > > > > > > >>>>> that > > > > > > > >>>>>> we cannot do in 1.x releases due to API compatibility > > > reasons, > > > > > so > > > > > > > >>> they > > > > > > > >>>>> are > > > > > > > >>>>>> postponed to 2.0. I would like to keep track of these > > tasks > > > in > > > > > > some > > > > > > > >>> way > > > > > > > >>>>> in > > > > > > > >>>>>> our Jira to make sure we do not have anything obsolete > > when > > > it > > > > > > > >> comes > > > > > > > >>> to > > > > > > > >>>>> the > > > > > > > >>>>>> next major version release. > > > > > > > >>>>>> > > > > > > > >>>>>> My question for now is how should we track such tasks? > > > Should > > > > it > > > > > > > >> be a > > > > > > > >>>>>> label, a parent task with subtasks, something else? > > > > > > > >>>>>> > > > > > > > >>>>>> I would go with a label + release version. > > > > > > > >>>>>> > > > > > > > >>>>>> --AG > > > > > > > >>>>>> > > > > > > > >>>>> > > > > > > > >>>> > > > > > > > >>> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Alexey Kuznetsov > > > > > > GridGain Systems > > > > > > www.gridgain.com > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sergey Kozlov > > > > GridGain Systems > > > > www.gridgain.com > > > > > > > > > > > > > > > -- > > Sergey Kozlov > > GridGain Systems > > www.gridgain.com > > > -- Sergey Kozlov GridGain Systems www.gridgain.com
