protected static class LuceneQueryEngine.LuceneAccessQuery extends AbstractAccessComponent
ProcessingComponent.DynamicOperationaccessNode, andedConstraints, limit, projectedColumns, sourceName| Constructor and Description |
|---|
LuceneQueryEngine.LuceneAccessQuery(LuceneSchema schema,
LuceneProcessingContext processingContext,
QueryContext context,
QueryResults.Columns resultColumns,
PlanNode accessNode) |
| Modifier and Type | Method and Description |
|---|---|
List<Object[]> |
execute()
Execute this stage of processing and return the resulting tuples that each conform to the
columns. |
close, createDynamicOperation, createSortComparator, emptyTuples, getColumns, getContext, getLocationIndexes, problemspublic LuceneQueryEngine.LuceneAccessQuery(LuceneSchema schema, LuceneProcessingContext processingContext, QueryContext context, QueryResults.Columns resultColumns, PlanNode accessNode)
public List<Object[]> execute()
columns.
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 Lucene Query.
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.
execute in class ProcessingComponentcolumns; never nullProcessingComponent.execute()Copyright © 2008-2014 JBoss, a division of Red Hat. All Rights Reserved.