|Constructor and Description|
|Modifier and Type||Method and Description|
Execute this stage of processing and return the resulting tuples that each conform to the
close, createDynamicOperation, createSortComparator, emptyTuples, getColumns, getContext, getLocationIndexes, problems
Some kinds of constraints are not easily pushed down to Lucene as are of a Lucene Query, and instead are applied by
filtering the results. For example, a
FullTextSearchScore applies to the score of the tuple, which cannot be
(easily?) applied as a
Therefore, each of the AND-ed constraints of the query are evaluated separately. After all, each of the tuples returned by the planned access query must satisfy all of the AND-ed constraints. Or, to put it another way, if a tuple does not satisfy one of the AND-ed constraints, the tuple should not be included in the query results.
Logically, any AND-ed criteria that cannot be pushed down to Lucene can of course be applied as a filter on the results. Thus, each AND-ed constraint is processed to first determine if it can be represented as a Lucene query; all other AND-ed constraints must be handled as a results filter. Since most queries will likely use one or more simple constraints AND-ed together, this approach will likely work very well.
The only hairy case is when any AND-ed constraint is actually an OR-ed combination of multiple constraints of which at least one cannot be pushed down to Lucene. In this case, the entire AND-ed constraint must be treated as a results filter (even if many of those constraints that make up the OR-ed constraint can be pushed down). Hopefully, this will not be a common case in actual queries.
Copyright © 2008-2014 JBoss, a division of Red Hat. All Rights Reserved.