On Tue, Dec 11, 2012 at 4:11 PM, Emmanuel Lécharny <[email protected]>wrote:
> Le 12/11/12 11:02 AM, Kiran Ayyagari a écrit : > > On Tue, Dec 11, 2012 at 3:23 PM, Emmanuel Lécharny <[email protected] > >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
