ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 11 Aug 2016 14:41:43 GMT
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 <skozlov@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 <dsetrakyan@apache.org>
> wrote:
>
> > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> akuznetsov@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 <dmagda@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 <yzhdanov@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 <dsetrakyan@apache.org
> >:
> > > > >
> > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <
> yzhdanov@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 <
> > dsetrakyan@apache.org
> > > >:
> > > > >>>
> > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov <
> > > yzhdanov@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.goncharuk@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message