When do the Filters turn into IndexAwareFilters ?

Question

Hi, I've looked through the documentation and this forum and probably found the answer already. But just to be sure ...
Re: Aggregation with a Partitioned Cache: unnecessary serialization This is post which i found useful for answering my question.
So am i right that any Filters which implement IndexAwareFilter interface (GreaterFilter, LessFilter, etc) start
behaving as a IndexAwareFilter after indexing the properties?
I've been looking for the solution which could optimize quering performance and it looks like there is only one choice. It's ok for me )) . When i started my search i thought about Extractors which could deal with POF format to extract some specific values without deserialing object. But in that case you still have to iterate over all values and cache those extracted values. The Coherence's indexing solution makes the same without requering additional effort from you.

Answer 1

Hi,
IndexAwareFilters are EntryFilters, but before iterating over the entire candidate set, they can first check whether there are applicable indexes they could use, and they do this before deserializing any entries.
This usually means that they check that an index exists for their extractor, and if yes, they use it, but there are exceptions, e.g. InKeySetFilter is an IndexAwareFilter, but it does not need any indexes to exist, it instead just filters the binary form of the keys.
So yes, most IndexAwareFilter give you a plus only if your extractor is indexed, but that is just because those kind of filters are provided.
As for extracting directly from the Binary form: one advantage is indeed that if an attribute is not indexed, then you don't need to pay the deserialization cost at querying, but there is a more significant advantage, too: you don't need to deserialize upon updates.
Coherence needs to deserialize your new entry value for updated entry or for an inserted entry on the storage node in case any of the following is true:
- an index is created on the cache which does not directly go into the Binary
- a map event filter-based cache listener or backing map listener is registered on the cache
- a backing map listener wants to examine the new value
- a map event transformer wants to transform the new value
Possibly most of these can benefit from not having to deserialize the entry if only Binary-aware extractors are used.
Best regards,
Robert