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 <[email protected]>: > 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 <[email protected]> > wrote: > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov < > [email protected]> > > 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 <[email protected]> > > 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 <[email protected]> > > > 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 <[email protected] > >: > > > > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov < > [email protected]> > > > > 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 < > > [email protected] > > > >: > > > > >>> > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < > > > [email protected]> > > > > >>>> 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 < > > > > >> [email protected] > > > > >>>> : > > > > >>>>> > > > > >>>>>> 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 >
