org.modeshape.jcr.query.lucene
Class LuceneQueryEngine.LuceneAccessQuery

java.lang.Object
  org.modeshape.jcr.query.process.ProcessingComponent
      org.modeshape.jcr.query.process.AbstractAccessComponent
          org.modeshape.jcr.query.lucene.LuceneQueryEngine.LuceneAccessQuery

Enclosing class:

LuceneQueryEngine

protected static class LuceneQueryEngine.LuceneAccessQuery
extends AbstractAccessComponent

The component that is created to represent a single access query and, when executed, transforms that access query into a single Lucene query and issues it against Lucene.

Nested Class Summary

Nested classes/interfaces inherited from class org.modeshape.jcr.query.process.ProcessingComponent

ProcessingComponent.DynamicOperation

Field Summary

Fields inherited from class org.modeshape.jcr.query.process.AbstractAccessComponent

accessNode, andedConstraints, limit, projectedColumns, sourceName

Constructor Summary

LuceneQueryEngine.LuceneAccessQuery(LuceneSchema schema, LuceneProcessingContext processingContext, QueryContext context, QueryResults.Columns resultColumns, PlanNode accessNode)

Method Summary

List<Object[]>

execute() Execute this stage of processing and return the resulting tuples that each conform to the columns.

Methods inherited from class org.modeshape.jcr.query.process.ProcessingComponent

close, createDynamicOperation, createSortComparator, emptyTuples, getColumns, getContext, problems

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

LuceneQueryEngine.LuceneAccessQuery

public LuceneQueryEngine.LuceneAccessQuery(LuceneSchema schema,
                                           LuceneProcessingContext processingContext,
                                           QueryContext context,
                                           QueryResults.Columns resultColumns,
                                           PlanNode accessNode)

Method Detail

execute

public List<Object[]> execute()

Execute this stage of processing and return the resulting tuples that each conform to the 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.

Specified by:

execute in class ProcessingComponent

Returns:

the list of tuples, where each tuple corresonds to the columns; never null

See Also:

ProcessingComponent.execute()