ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 11 Aug 2016 15:06:52 GMT
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.vladykin@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 <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
> >
>



-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

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