Of course it does, Dmitriy! However as I suggested below, the feature should be optional. The current behavior (not requiring user classes on the server, etc.) would remain the default one.
Also, please realize that not everyone stores their data as POJOs or uses Ignite as a JDBC source -- the use cases that appear to have been the main focus of Ignite community lately. Payloads with dynamic structures require more advanced mechanisms for indexing, for example, to avoid the overhead of duplicating the indexable fields as top level fields of the 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 memory utilization. In Ignite community finds this feature generally useful, I'd be more than happy to contribute its implementation. 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.com> 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 Ignite at the cache entry indexing time. > > My point is that rather than limiting indexable fields only to predefined > POJO attributes (or BinaryObject fields) Ignite could adopt a more general > approach by allowing users designate an arbitrary piece of code (a > lambda/closure) to be used as an index value extractor. In such case, the > current functionality (extracting index values from POJO attributes) > becomes just a special case that's supported by Ignite out of the box. > Andrey, this would require deserialization on the server side. It would also require that user classes are present on the server side. Both of this scenarios Ignite tries to avoid. Makes sense?
