On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <skoz...@gridgain.com> wrote:
> 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. > Sergey K, setting the same SQL schema for multiple caches, as proposed by Sergi, solves a different problem of having too many SQL schemas due to too many different caches. I think Sergi proposed a good solution for it. > > 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 >
