Hi,
I'm not quite sure what you are trying to do. You don't need to do the
multiplexing *within* your index. Let the query engine do the multiplexing.
> Would it be safe to assume that IndexPlan instance returned from the
>getPlans call would be passed back in the {{query}} call?
Yes, the index plan is of of the plans that the index returned in the
getPlans call.
> having multiple Lucene indexes
You could simply have *multiple* index instances, and each index returns
its own cost or plan(s). The query engine will figure out which index to
use.
As for OAK-2005, you *could* implement the AdvanceQueryIndex. Actually it
would be nice if that's implemented (just in general). But you *have* to:
you could just implement a regular QueryIndex, and return the cost or
infinity. If you implement AdvanceQueryIndex, return either none or one
IndexPlan. No need to return multiple IndexPlan.
Regards,
Thomas
On 31/07/14 12:57, "Chetan Mehrotra" <[email protected]> wrote:
>Hi,
>
>While working on multiple Lucene index support (OAK-2005) I need to
>make LuceneIndex implement the AdvanceQueryIndex. As part of OAK-2005
>we would be having multiple Lucene indexes where each index would be
>configured to store different types of data.
>
>As part of getPlans call LuceneIndex would be returning multiple
>IndexPlans depending on which index meet the Filter criteria upto what
>level. In doing that LuceneIndex would have already determined the
>Lucene index it can use for that plan. This information can then be
>used to pickup the required Index when actual {{query}} method is
>invoked with given plan
>
>Would it be ok to provide a custom impl of IndexPlan which embeds
>LuceneIndex related custom data like which index to use for this plan?
>Would it be safe to assume that IndexPlan instance returned from the
>getPlans call would be passed back in the {{query}} call?
>
>Chetan Mehrotra
