Dmitriy, you have agreed with me in the old thread, and now you don't? Binarylizable (current) is longer than Binarizable (proposed).
On Wed, Jul 20, 2016 at 10:24 AM, Dmitriy Setrakyan <dsetrak...@gridgain.com > wrote: > > > > > On Jul 20, 2016, at 9:17 AM, Pavel Tupitsyn <ptupit...@gridgain.com> > 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 < > sergi.vlady...@gmail.com> > > 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 < > >> valentin.kuliche...@gmail.com> 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 < > >>> akuznet...@gridgain.com> > >>> 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" < > >>>> sergi.vlady...@gmail.com> > >>>> написал: > >>>> > >>>> 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 < > andrey4...@gmail.com > >>> > >>>> wrote: > >>>> > >>>>> > >>>>> 15.07.2016 0:31, Dmitriy Setrakyan пишет: > >>>>> > >>>>>> On Fri, Jul 15, 2016 at 12:26 AM, AndreyVel<andrey4...@gmail.com> > >>>> 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. > >>>>> > >>>> > >>> > >> >
