On Tue, Dec 11, 2012 at 4:11 PM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
Le 12/11/12 11:02 AM, Kiran Ayyagari a écrit :
> On Tue, Dec 11, 2012 at 3:23 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:
>
>> But, and there is a big but, when processing a search request, we do a
>> 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
> interceptor

Because Lookup does not use a cursor at all :/ OTOH, cursors are based
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 )...


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com




--
Kiran Ayyagari
http://keydap.com