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 >
