Apache Ignite Developers - Legacy Mail Archive

Ignite 2.0 tasks/roadmap

Classic

List

Threaded

56 messages Options

123

Alexey Goncharuk

Ignite 2.0 tasks/roadmap

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 Goncharuk

Re: Ignite 2.0 tasks/roadmap

So, no excitement about Ignite 2.0? :)

I went ahead and created a 2.0 version in Ignite Jira, and included the
following tickets so far based on the chance that this ticket will require
breaking changes in APIs/Configuration
- IGNITE-3469 - Get rid of deprecated APIs and code
- IGNTIE-3477 - Rework offheap storage
- IGNITE-3478 - Transactional SQL
- IGNITE-1605 - Provide stronger data loss check
- IGNITE-3306 - Extend IgniteCluster interface with the methods to send
and receive custom discovery events

I believe that there are many more changes that we wanted to make but
delayed because they would break binary compatibility, so if you have
something in mind - it's time to create a ticket or assign it to 2.0 if it
exists. It's good to know the scope of work.

Also, it would be great if you review/comment the above-mentioned tickets.

Thanks,
AG

yzhdanov

Re: Ignite 2.0 tasks/roadmap

Alex, a lot of excitement for Ignite-2.0 from my side! =)

I agree with your points and I will take a close look at them in the
nearest future.

Here are some suggestions from me.

I don't remember if I shared my thoughts on moving to single TCP port per
node. So, I filed a new ticket -
https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
another one let's merge them.

I would also think over removing communication SPI and discovery SPI and
introducing communication and discovery processors instead. In some places
Ignite pretty much relies on internal implementation details of these SPIs
which makes implementation of any other SPI pretty complex task. Btw, did
anyone did that? Removing SPIs will allow us to cleanup the code and use
common abstractions and logic.

I will give some more ideas going forward.

Thanks!

--Yakov

2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <[hidden email]>:

> So, no excitement about Ignite 2.0? :)
>
> I went ahead and created a 2.0 version in Ignite Jira, and included the
> following tickets so far based on the chance that this ticket will require
> breaking changes in APIs/Configuration
> - IGNITE-3469 - Get rid of deprecated APIs and code
> - IGNTIE-3477 - Rework offheap storage
> - IGNITE-3478 - Transactional SQL
> - IGNITE-1605 - Provide stronger data loss check
> - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
> and receive custom discovery events
>
> I believe that there are many more changes that we wanted to make but
> delayed because they would break binary compatibility, so if you have
> something in mind - it's time to create a ticket or assign it to 2.0 if it
> exists. It's good to know the scope of work.
>
> Also, it would be great if you review/comment the above-mentioned tickets.
>
> Thanks,
> AG
>

Vladimir Ozerov

Re: Ignite 2.0 tasks/roadmap

Several points from my side:
1) Java 9 support - Unsafe removal, modules, etc..
2) Rework our "messages" subsystem - we always read/write all fields, thus
transferring lots of zeros without any reason. We should support branching.
3) Review all messages (especially cache, double-especially - atomic) in
terms of performance. Most probably we will refactor/split some of them.

14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <[hidden email]>
написал:

> Alex, a lot of excitement for Ignite-2.0 from my side! =)
>
> I agree with your points and I will take a close look at them in the
> nearest future.
>
> Here are some suggestions from me.
>
> I don't remember if I shared my thoughts on moving to single TCP port per
> node. So, I filed a new ticket -
> https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> another one let's merge them.
>
> I would also think over removing communication SPI and discovery SPI and
> introducing communication and discovery processors instead. In some places
> Ignite pretty much relies on internal implementation details of these SPIs
> which makes implementation of any other SPI pretty complex task. Btw, did
> anyone did that? Removing SPIs will allow us to cleanup the code and use
> common abstractions and logic.
>
> I will give some more ideas going forward.
>
> Thanks!
>
> --Yakov
>
> 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <[hidden email]>:
>
> > So, no excitement about Ignite 2.0? :)
> >
> > I went ahead and created a 2.0 version in Ignite Jira, and included the
> > following tickets so far based on the chance that this ticket will
> require
> > breaking changes in APIs/Configuration
> > - IGNITE-3469 - Get rid of deprecated APIs and code
> > - IGNTIE-3477 - Rework offheap storage
> > - IGNITE-3478 - Transactional SQL
> > - IGNITE-1605 - Provide stronger data loss check
> > - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
> > and receive custom discovery events
> >
> > I believe that there are many more changes that we wanted to make but
> > delayed because they would break binary compatibility, so if you have
> > something in mind - it's time to create a ticket or assign it to 2.0 if
> it
> > exists. It's good to know the scope of work.
> >
> > Also, it would be great if you review/comment the above-mentioned
> tickets.
> >
> > Thanks,
> > AG
> >
>

yzhdanov

Re: Ignite 2.0 tasks/roadmap

Vova, 2) even long zero is encoded as 1 byte now. Do you think it is a
problem?

--Yakov

2016-07-14 16:09 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> Several points from my side:
> 1) Java 9 support - Unsafe removal, modules, etc..
> 2) Rework our "messages" subsystem - we always read/write all fields, thus
> transferring lots of zeros without any reason. We should support branching.
> 3) Review all messages (especially cache, double-especially - atomic) in
> terms of performance. Most probably we will refactor/split some of them.
>
> 14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <[hidden email]>
> написал:
>
> > Alex, a lot of excitement for Ignite-2.0 from my side! =)
> >
> > I agree with your points and I will take a close look at them in the
> > nearest future.
> >
> > Here are some suggestions from me.
> >
> > I don't remember if I shared my thoughts on moving to single TCP port per
> > node. So, I filed a new ticket -
> > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> > another one let's merge them.
> >
> > I would also think over removing communication SPI and discovery SPI and
> > introducing communication and discovery processors instead. In some
> places
> > Ignite pretty much relies on internal implementation details of these
> SPIs
> > which makes implementation of any other SPI pretty complex task. Btw, did
> > anyone did that? Removing SPIs will allow us to cleanup the code and use
> > common abstractions and logic.
> >
> > I will give some more ideas going forward.
> >
> > Thanks!
> >
> > --Yakov
> >
> > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <[hidden email]>:
> >
> > > So, no excitement about Ignite 2.0? :)
> > >
> > > I went ahead and created a 2.0 version in Ignite Jira, and included the
> > > following tickets so far based on the chance that this ticket will
> > require
> > > breaking changes in APIs/Configuration
> > > - IGNITE-3469 - Get rid of deprecated APIs and code
> > > - IGNTIE-3477 - Rework offheap storage
> > > - IGNITE-3478 - Transactional SQL
> > > - IGNITE-1605 - Provide stronger data loss check
> > > - IGNITE-3306 - Extend IgniteCluster interface with the methods to
> send
> > > and receive custom discovery events
> > >
> > > I believe that there are many more changes that we wanted to make but
> > > delayed because they would break binary compatibility, so if you have
> > > something in mind - it's time to create a ticket or assign it to 2.0 if
> > it
> > > exists. It's good to know the scope of work.
> > >
> > > Also, it would be great if you review/comment the above-mentioned
> > tickets.
> > >
> > > Thanks,
> > > AG
> > >
> >
>

dsetrakyan

Re: Ignite 2.0 tasks/roadmap

In reply to this post by Vladimir Ozerov

Vova, why Unsafe removal? To my knowledge, Unsafe still remains in Java 9,
no?

On Thu, Jul 14, 2016 at 4:09 PM, Vladimir Ozerov <[hidden email]>
wrote:

Vladimir Ozerov

Re: Ignite 2.0 tasks/roadmap

Yakov, I am not sure we fixed it. Plus sometimes we encode missing value as
-1, so it is written as 4 bytes still.

Dmitry, to my knowledge Unsafe will be available only when special VM flag
is set. It is not a problem for ignite.sh, but may cause usability issues
when running in embedded mode. Moreover, some methods will be removed from
Unsafe, e.g. monitorEnter(). So I doubt we even compilable with Java 9 now.

14 июля 2016 г. 16:27 пользователь "Dmitriy Setrakyan" <
[hidden email]> написал:

> Vova, why Unsafe removal? To my knowledge, Unsafe still remains in Java 9,
> no?
>
> On Thu, Jul 14, 2016 at 4:09 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Several points from my side:
> > 1) Java 9 support - Unsafe removal, modules, etc..
> > 2) Rework our "messages" subsystem - we always read/write all fields,
> thus
> > transferring lots of zeros without any reason. We should support
> branching.
> > 3) Review all messages (especially cache, double-especially - atomic) in
> > terms of performance. Most probably we will refactor/split some of them.
> >
> > 14 июля 2016 г. 12:06 пользователь "Yakov Zhdanov" <[hidden email]>
> > написал:
> >
> > > Alex, a lot of excitement for Ignite-2.0 from my side! =)
> > >
> > > I agree with your points and I will take a close look at them in the
> > > nearest future.
> > >
> > > Here are some suggestions from me.
> > >
> > > I don't remember if I shared my thoughts on moving to single TCP port
> per
> > > node. So, I filed a new ticket -
> > > https://issues.apache.org/jira/browse/IGNITE-3480. If we already have
> > > another one let's merge them.
> > >
> > > I would also think over removing communication SPI and discovery SPI
> and
> > > introducing communication and discovery processors instead. In some
> > places
> > > Ignite pretty much relies on internal implementation details of these
> > SPIs
> > > which makes implementation of any other SPI pretty complex task. Btw,
> did
> > > anyone did that? Removing SPIs will allow us to cleanup the code and
> use
> > > common abstractions and logic.
> > >
> > > I will give some more ideas going forward.
> > >
> > > Thanks!
> > >
> > > --Yakov
> > >
> > > 2016-07-14 4:43 GMT+03:00 Alexey Goncharuk <[hidden email]
> >:
> > >
> > > > So, no excitement about Ignite 2.0? :)
> > > >
> > > > I went ahead and created a 2.0 version in Ignite Jira, and included
> the
> > > > following tickets so far based on the chance that this ticket will
> > > require
> > > > breaking changes in APIs/Configuration
> > > > - IGNITE-3469 - Get rid of deprecated APIs and code
> > > > - IGNTIE-3477 - Rework offheap storage
> > > > - IGNITE-3478 - Transactional SQL
> > > > - IGNITE-1605 - Provide stronger data loss check
> > > > - IGNITE-3306 - Extend IgniteCluster interface with the methods to
> > send
> > > > and receive custom discovery events
> > > >
> > > > I believe that there are many more changes that we wanted to make but
> > > > delayed because they would break binary compatibility, so if you have
> > > > something in mind - it's time to create a ticket or assign it to 2.0
> if
> > > it
> > > > exists. It's good to know the scope of work.
> > > >
> > > > Also, it would be great if you review/comment the above-mentioned
> > > tickets.
> > > >
> > > > Thanks,
> > > > AG
> > > >
> > >
> >
>

Alexey Kuznetsov-2

Re: Ignite 2.0 tasks/roadmap

Several points from my side:
1) Drop support for null cache names
2) rework Visor data transfer objects to binary format in order to easily
extend them if needed.

AndreyVel

Re: Ignite 2.0 tasks/roadmap

In reply to this post by Alexey Goncharuk

Good feature may be Aggregated cache - analog materialized view in DBMS
Aggregated cache is great for performance (KPI, analytecal reports).

Recently I learned network traffic between nodes when node
restart/startup and do no found any compressing for transferred data.

I know there is IgniteDataStreamer for writing cache, but how about
reading cache as stream for iterate all elements with scan performane
1-3M tuple/sec?

14.07.2016 4:43, Alexey Goncharuk пишет:

dsetrakyan

Re: Ignite 2.0 tasks/roadmap

On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel <[hidden email]> wrote:

> Good feature may be Aggregated cache - analog materialized view in DBMS
> Aggregated cache is great for performance (KPI, analytecal reports).
>

Do you mean a copy of the aggregated data in another cache? What happens
when the data in the original caches is updated?

>
> Recently I learned network traffic between nodes when node restart/startup
> and do no found any compressing for transferred data.
>

Agree, we should allow users compress the data. I am not an expert on
Ignite messaging, but would be nice if some of the committers could comment
on this.

>
> I know there is IgniteDataStreamer for writing cache, but how about
> reading cache as stream for iterate all elements with scan performane 1-3M
> tuple/sec?
>

We already have Scan queries which allow for paginated iteration with
filters. Are you suggesting something beyond this?

>
>
> 14.07.2016 4:43, Alexey Goncharuk пишет:
>
> So, no excitement about Ignite 2.0? :)
>>
>> I went ahead and created a 2.0 version in Ignite Jira, and included the
>> following tickets so far based on the chance that this ticket will require
>> breaking changes in APIs/Configuration
>> - IGNITE-3469 - Get rid of deprecated APIs and code
>> - IGNTIE-3477 - Rework offheap storage
>> - IGNITE-3478 - Transactional SQL
>> - IGNITE-1605 - Provide stronger data loss check
>> - IGNITE-3306 - Extend IgniteCluster interface with the methods to send
>> and receive custom discovery events
>>
>> I believe that there are many more changes that we wanted to make but
>> delayed because they would break binary compatibility, so if you have
>> something in mind - it's time to create a ticket or assign it to 2.0 if it
>> exists. It's good to know the scope of work.
>>
>> Also, it would be great if you review/comment the above-mentioned tickets.
>>
>> Thanks,
>> AG
>>
>>
>

Alexey Goncharuk

Re: Ignite 2.0 tasks/roadmap

In reply to this post by Alexey Kuznetsov-2

Great stuff! Guys, please go ahead and file corresponding tickets or
reassign the fix version to 2.0 if a ticket exists so that we keep track of
the scope. It would also be great if you review the ones I created and see
if they make sense.

Alexey Goncharuk

Re: Ignite 2.0 tasks/roadmap

In reply to this post by dsetrakyan

>
> >
> > I know there is IgniteDataStreamer for writing cache, but how about
> > reading cache as stream for iterate all elements with scan performane
> 1-3M
> > tuple/sec?
> >
>
> We already have Scan queries which allow for paginated iteration with
> filters. Are you suggesting something beyond this?

I like the idea of DataStreamer approach for scanning a cache. I think it
would be nice to have a way to iterate over cache partitions in parallel,
similar to forEachPartition() method in Spark RDD.

Benefits compared to current Scan query:
* Parallel execution for different partitions
* Bringing computation to data, not data to client.

Of course, this can already be implemented by a user with local scan query
+ compute task, but having an utility method on an API will cut a lot of
boilerplate code for users.

dsetrakyan

Re: Ignite 2.0 tasks/roadmap

On Fri, Jul 15, 2016 at 1:49 AM, Alexey Goncharuk <
[hidden email]> wrote:

> >
> > >
> > > I know there is IgniteDataStreamer for writing cache, but how about
> > > reading cache as stream for iterate all elements with scan performane
> > 1-3M
> > > tuple/sec?
> > >
> >
> > We already have Scan queries which allow for paginated iteration with
> > filters. Are you suggesting something beyond this?
>
>
> I like the idea of DataStreamer approach for scanning a cache. I think it
> would be nice to have a way to iterate over cache partitions in parallel,
> similar to forEachPartition() method in Spark RDD.
>
> Benefits compared to current Scan query:
> * Parallel execution for different partitions
> * Bringing computation to data, not data to client.
>
> Of course, this can already be implemented by a user with local scan query
> + compute task, but having an utility method on an API will cut a lot of
> boilerplate code for users.
>

Got it now. Sounds very useful. I think we should definitely create a
ticket for it and see if anyone in the community will pick it up. Sounds
like it won’t be too difficult to implement.

AndreyVel

Re: Ignite 2.0 tasks/roadmap

In reply to this post by dsetrakyan

15.07.2016 0:31, Dmitriy Setrakyan пишет:
> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<[hidden email]> wrote:
>
>> Good feature may be Aggregated cache - analog materialized view in DBMS
>> Aggregated cache is great for performance (KPI, analytecal reports).
>>
> Do you mean a copy of the aggregated data in another cache? What happens
> when the data in the original caches is updated?
>
>

Yes, aggregated data can be store in another cache,
embedded aggregating cache can be updated sync/async. Aggregating from
the box has better performance then creating custom event listeners.

If cache entry updated/deleted aggregate listener can get 2 values old
and new.

Sergi

Re: Ignite 2.0 tasks/roadmap

Huge +1 for dropping support for null in all names, not only for cache
names. Do we have ticket for this one?

Sergi

On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <[hidden email]>
wrote:

>
> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>
>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<[hidden email]> wrote:
>>
>> Good feature may be Aggregated cache - analog materialized view in DBMS
>>> Aggregated cache is great for performance (KPI, analytecal reports).
>>>
>>> Do you mean a copy of the aggregated data in another cache? What happens
>> when the data in the original caches is updated?
>>
>>
>>
> Yes, aggregated data can be store in another cache,
> embedded aggregating cache can be updated sync/async. Aggregating from the
> box has better performance then creating custom event listeners.
>
> If cache entry updated/deleted aggregate listener can get 2 values old and
> new.
>

Alexey Kuznetsov-2

Re: Ignite 2.0 tasks/roadmap

Sergi, that was my idea to drop nulls but I have limited access to internet
(I'm on vacation) could you create issue in JIRA?

Thanks.

Alexey Kuznetsov

15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <[hidden email]>
написал:

Huge +1 for dropping support for null in all names, not only for cache
names. Do we have ticket for this one?

Sergi

On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <[hidden email]>
wrote:

Valentin Kulichenko

Re: Ignite 2.0 tasks/roadmap

Folks,

I created one more ticket related to SQL:
https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability issue
that pops up on user forum every now and then. Since it's a compatibility
breaking changed, it looks like a good candidate for 2.0.

-Val

On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <[hidden email]>
wrote:

> Sergi, that was my idea to drop nulls but I have limited access to internet
> (I'm on vacation) could you create issue in JIRA?
>
> Thanks.
>
> Alexey Kuznetsov
>
> 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
> [hidden email]>
> написал:
>
> Huge +1 for dropping support for null in all names, not only for cache
> names. Do we have ticket for this one?
>
> Sergi
>
> On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <[hidden email]>
> wrote:
>
> >
> > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> >
> >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<[hidden email]>
> wrote:
> >>
> >> Good feature may be Aggregated cache - analog materialized view in DBMS
> >>> Aggregated cache is great for performance (KPI, analytecal reports).
> >>>
> >>> Do you mean a copy of the aggregated data in another cache? What
> happens
> >> when the data in the original caches is updated?
> >>
> >>
> >>
> > Yes, aggregated data can be store in another cache,
> > embedded aggregating cache can be updated sync/async. Aggregating from
> the
> > box has better performance then creating custom event listeners.
> >
> > If cache entry updated/deleted aggregate listener can get 2 values old
> and
> > new.
> >
>

Sergi

Re: Ignite 2.0 tasks/roadmap

Alexey K.,

No problem, here it is https://issues.apache.org/jira/browse/IGNITE-3488

Sergi

On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko <
[hidden email]> wrote:

> Folks,
>
> I created one more ticket related to SQL:
> https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability issue
> that pops up on user forum every now and then. Since it's a compatibility
> breaking changed, it looks like a good candidate for 2.0.
>
> -Val
>
> On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <
> [hidden email]>
> wrote:
>
> > Sergi, that was my idea to drop nulls but I have limited access to
> internet
> > (I'm on vacation) could you create issue in JIRA?
> >
> > Thanks.
> >
> > Alexey Kuznetsov
> >
> > 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
> > [hidden email]>
> > написал:
> >
> > Huge +1 for dropping support for null in all names, not only for cache
> > names. Do we have ticket for this one?
> >
> > Sergi
> >
> > On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <[hidden email]>
> > wrote:
> >
> > >
> > > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> > >
> > >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<[hidden email]>
> > wrote:
> > >>
> > >> Good feature may be Aggregated cache - analog materialized view in
> DBMS
> > >>> Aggregated cache is great for performance (KPI, analytecal reports).
> > >>>
> > >>> Do you mean a copy of the aggregated data in another cache? What
> > happens
> > >> when the data in the original caches is updated?
> > >>
> > >>
> > >>
> > > Yes, aggregated data can be store in another cache,
> > > embedded aggregating cache can be updated sync/async. Aggregating from
> > the
> > > box has better performance then creating custom event listeners.
> > >
> > > If cache entry updated/deleted aggregate listener can get 2 values old
> > and
> > > new.
> > >
> >
>

Pavel Tupitsyn-3

Re: Ignite 2.0 tasks/roadmap

How about renaming Binarylizable interface?

http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html

On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <[hidden email]>
wrote:

> Alexey K.,
>
> No problem, here it is https://issues.apache.org/jira/browse/IGNITE-3488
>
> Sergi
>
> On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko <
> [hidden email]> wrote:
>
> > Folks,
> >
> > I created one more ticket related to SQL:
> > https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability
> issue
> > that pops up on user forum every now and then. Since it's a compatibility
> > breaking changed, it looks like a good candidate for 2.0.
> >
> > -Val
> >
> > On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <
> > [hidden email]>
> > wrote:
> >
> > > Sergi, that was my idea to drop nulls but I have limited access to
> > internet
> > > (I'm on vacation) could you create issue in JIRA?
> > >
> > > Thanks.
> > >
> > > Alexey Kuznetsov
> > >
> > > 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
> > > [hidden email]>
> > > написал:
> > >
> > > Huge +1 for dropping support for null in all names, not only for cache
> > > names. Do we have ticket for this one?
> > >
> > > Sergi
> > >
> > > On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <[hidden email]
> >
> > > wrote:
> > >
> > > >
> > > > 15.07.2016 0:31, Dmitriy Setrakyan пишет:
> > > >
> > > >> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<[hidden email]>
> > > wrote:
> > > >>
> > > >> Good feature may be Aggregated cache - analog materialized view in
> > DBMS
> > > >>> Aggregated cache is great for performance (KPI, analytecal
> reports).
> > > >>>
> > > >>> Do you mean a copy of the aggregated data in another cache? What
> > > happens
> > > >> when the data in the original caches is updated?
> > > >>
> > > >>
> > > >>
> > > > Yes, aggregated data can be store in another cache,
> > > > embedded aggregating cache can be updated sync/async. Aggregating
> from
> > > the
> > > > box has better performance then creating custom event listeners.
> > > >
> > > > If cache entry updated/deleted aggregate listener can get 2 values
> old
> > > and
> > > > new.
> > > >
> > >
> >
>

Dmitriy Setrakyan

Re: Ignite 2.0 tasks/roadmap

> On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn <[hidden email]> wrote:
>
> How about renaming Binarylizable interface?
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Naming-Binarylizable-td4592.html

Pavel, I would not rename. The name you are suggesting is very hard to pronounce.

>
> On Sat, Jul 16, 2016 at 10:25 AM, Sergi Vladykin <[hidden email]>
> wrote:
>
>> Alexey K.,
>>
>> No problem, here it is https://issues.apache.org/jira/browse/IGNITE-3488
>>
>> Sergi
>>
>> On Sat, Jul 16, 2016 at 2:00 AM, Valentin Kulichenko <
>> [hidden email]> wrote:
>>
>>> Folks,
>>>
>>> I created one more ticket related to SQL:
>>> https://issues.apache.org/jira/browse/IGNITE-3487. It's a usability
>> issue
>>> that pops up on user forum every now and then. Since it's a compatibility
>>> breaking changed, it looks like a good candidate for 2.0.
>>>
>>> -Val
>>>
>>> On Fri, Jul 15, 2016 at 11:56 AM, Alexey Kuznetsov <
>>> [hidden email]>
>>> wrote:
>>>
>>>> Sergi, that was my idea to drop nulls but I have limited access to
>>> internet
>>>> (I'm on vacation) could you create issue in JIRA?
>>>>
>>>> Thanks.
>>>>
>>>> Alexey Kuznetsov
>>>>
>>>> 15 Июл 2016 г. 15:17 пользователь "Sergi Vladykin" <
>>>> [hidden email]>
>>>> написал:
>>>>
>>>> Huge +1 for dropping support for null in all names, not only for cache
>>>> names. Do we have ticket for this one?
>>>>
>>>> Sergi
>>>>
>>>> On Fri, Jul 15, 2016 at 2:00 PM, Andrey Velichko <[hidden email]
>>>
>>>> wrote:
>>>>
>>>>>
>>>>> 15.07.2016 0:31, Dmitriy Setrakyan пишет:
>>>>>
>>>>>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<[hidden email]>
>>>> wrote:
>>>>>>
>>>>>> Good feature may be Aggregated cache - analog materialized view in
>>> DBMS
>>>>>>> Aggregated cache is great for performance (KPI, analytecal
>> reports).
>>>>>>>
>>>>>>> Do you mean a copy of the aggregated data in another cache? What
>>>> happens
>>>>>> when the data in the original caches is updated?
>>>>>>
>>>>>>
>>>>>>
>>>>> Yes, aggregated data can be store in another cache,
>>>>> embedded aggregating cache can be updated sync/async. Aggregating
>> from
>>>> the
>>>>> box has better performance then creating custom event listeners.
>>>>>
>>>>> If cache entry updated/deleted aggregate listener can get 2 values
>> old
>>>> and
>>>>> new.
>>>>>
>>>>
>>>
>>

123