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
