BinaryObjects. In cases where the
> > cache
> > > > sizes are in tens of millions of entries, the ability to generate
> index
> > > > values on the fly rather than store them, would go a long way in
> terms
> > of
> > > > reducing
t; reducing memory utilization.
> > >
> > > In Ignite community finds this feature generally useful, I'd be more
> than
> > > happy to contribute its implementation.
> > >
> > > Regards
> > > Andrey
> > >
> > > _
ther than store them, would go a long way in terms of
> > reducing memory utilization.
> >
> > In Ignite community finds this feature generally useful, I'd be more than
> > happy to contribute its implementation.
> >
> > Regards
> > Andrey
> >
> >
s
> Andrey
>
>
> From: Dmitriy Setrakyan <dsetrak...@apache.org>
> Sent: Monday, October 16, 2017 6:14 PM
> To: dev@ignite.apache.org
> Subject: Re: Indexing fields of non-POJO cache values
>
> On Mon, Oct 16, 2017 at 12:35 PM, Andre
.
Regards
Andrey
From: Dmitriy Setrakyan <dsetrak...@apache.org>
Sent: Monday, October 16, 2017 6:14 PM
To: dev@ignite.apache.org
Subject: Re: Indexing fields of non-POJO cache values
On Mon, Oct 16, 2017 at 12:35 PM, Andrey Kornev <andrewkor...@hotmail.c
On Mon, Oct 16, 2017 at 12:35 PM, Andrey Kornev
wrote:
> [Crossposting to the dev list]
>
> Alexey,
>
> Yes, something like that, where the "reference"/"alias" is expressed as a
> piece of Java code (as part of QueryEntity definition, perhaps) that is
> invoked by
ursday, October 12, 2017 5:53 PM
To: u...@ignite.apache.org
Subject: Re: Indexing fields of non-POJO cache values
Just as idea.
What if we can to declare a kind of "references" or "aliases" for fields in
such cases?
And this will help us to avoid duplication of data.
For ex