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 example in JavaScript I could (almost on the fly) declare getters and setters that could be as aliases for my data. On Fri, Oct 13, 2017 at 12:39 AM, Andrey Kornev <[email protected]> wrote: > Hey Andrey, > > Thanks for your reply! > > We've been using a slightly different approach, where we extract the > values of the indexable leaf nodes and store them as individual fields of > the binary object along with the serialized tree itself. Then we configure > the cache to use those fields as QueryEntities. It works fine and this way > we avoid using joins in our queries. > > However an obvious drawback of such approach is data duplication. We end > up with three copies of a field value: > > 1) the leaf node of the tree, > 2) the field of the binary object, and > 3) Ignite index > > I was hoping that there may be a better way to achieve this. In particular > I'd like to avoid storing the value as a field of a binary object (copy #2). > > One possible (and elegant) approach to solving this problem would be to > introduce a way to specify a method (or a closure) for a QueryEntity in > addition to currently supported BinaryObject field/POJO attribute. > > Regards > Andrey > > ------------------------------ > *From:* Andrey Mashenkov <[email protected]> > *Sent:* Thursday, October 12, 2017 6:25 AM > *To:* [email protected] > *Subject:* Re: Indexing fields of non-POJO cache values > > Hi, > > Another way here is to implement your own query engine by extending > IndexingSPI interface, which looks much more complicated. > > On Thu, Oct 12, 2017 at 4:23 PM, Andrey Mashenkov < > [email protected]> wrote: > >> Hi, >> >> There is no way to index such data as is. To index data you need to have >> entry_field<->column mapping configured. >> As a workaround here, leaves can be stored in cache as values. >> >> E.g. you can have a separate cache to index leaf nodes, where entries >> will have 2 fields: "original tree key" field and "leaf node value" indexed >> field. >> So, you will be able to query serialized tree-like structures via SQL >> query with JOIN condition on "original tree key" and WHERE condition on >> "leaf node value" field. >> Obviously, you will need to implement intermediate logic to keep data of >> both caches consistent. >> >> >> On Wed, Oct 11, 2017 at 9:40 PM, Andrey Kornev <[email protected]> >> wrote: >> >>> Hello, >>> >>> Consider the following use case: my cache values are a >>> serialized tree-like structure (as opposed to a POJO). The leaf nodes of >>> the tree are Java primitives. Some of the leaf nodes are used by the >>> queries and should be indexed. >>> >>> What are my options for indexing such data? >>> >>> Thanks >>> Andrey >>> >> >> >> >> -- >> Best regards, >> Andrey V. Mashenkov >> > > > > -- > Best regards, > Andrey V. Mashenkov > -- Alexey Kuznetsov
