On Tue, Dec 11, 2012 at 4:11 PM, Emmanuel Lécharny <email@example.com>
Le 12/11/12 11:02 AM, Kiran Ayyagari a écrit :
>> But, and there is a big but, when processing a search request, we do aBecause Lookup does not use a cursor at all :/ OTOH, cursors are based
>> direct lookup from the backend, and we are not going through this chain.
>> What happens is that we are building a list of filters, and we apply
>> this list of filters on every entry fetched from the backend doing a
>> direct lookup. So the filter added by the SchemaInterceptor should also
>> do this filtering.
>> as the filtering is only applicable for search(and lookup) why not apply
> this logic in the cursor
> after evaluating an entry, I know that this filtering logic was scattered
> before but with all that
> moved to a utility class I think using that inside the cursor is the right
> thing rather than doing it in an
on lookup (but not the same as for the lookup() operation.
but unlike in lookup(LookupOperationContext) we don't need to filter anything in lookup(id) method
/me is wondering if we should not rename the lookup( id ) in the
Partition interface to fetch( id )...