You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Chetan Mehrotra <ch...@gmail.com> on 2014/07/31 12:57:14 UTC
Extending the IndexPlan with custom data
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
Re: Extending the IndexPlan with custom data
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Thu, Jul 31, 2014 at 7:01 PM, Tommaso Teofili
<to...@gmail.com> wrote:
> as far as I know one workaround to trigger usage of a specific index is to
> use the native language supported by that specific index, but then that, of
> course, would require writing the query in a implementation specific way
> (e.g. select * from [nt:base] where native('lucene','title:foo -title:bar')
> ).
Yup that would work. So I can have native type as the lucene index
name which say has index for only a limited subset of properties
tailor made for a particular query and then it can be used. And yes it
would be implementation specific
Chetan Mehrotra
Re: Extending the IndexPlan with custom data
Posted by Tommaso Teofili <to...@gmail.com>.
2014-07-31 15:20 GMT+02:00 Chetan Mehrotra <ch...@gmail.com>:
> On Thu, Jul 31, 2014 at 5:23 PM, Thomas Mueller <mu...@adobe.com> wrote:
> > 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.
>
> Aah missed the fact that QueryProvider can return multiple indexes.
> That would simplify things!
>
> > 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.
>
> The interest in AdvanceQueryIndex was to support ordering. Filter does
> not provide any info wrt ordering requirement. IndexPlan provides
> access to ordering information which can be used to order results in
> Lucene. So would go with the suggestion of returning one plan per
> index.
>
> btw any plans to add hint support to force usage of specific index?
>
as far as I know one workaround to trigger usage of a specific index is to
use the native language supported by that specific index, but then that, of
course, would require writing the query in a implementation specific way
(e.g. select * from [nt:base] where native('lucene','title:foo -title:bar')
).
Regards,
Tommaso
> Chetan Mehrotra
>
Re: Extending the IndexPlan with custom data
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Thu, Jul 31, 2014 at 5:23 PM, Thomas Mueller <mu...@adobe.com> wrote:
> 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.
Aah missed the fact that QueryProvider can return multiple indexes.
That would simplify things!
> 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.
The interest in AdvanceQueryIndex was to support ordering. Filter does
not provide any info wrt ordering requirement. IndexPlan provides
access to ordering information which can be used to order results in
Lucene. So would go with the suggestion of returning one plan per
index.
btw any plans to add hint support to force usage of specific index?
Chetan Mehrotra
Re: Extending the IndexPlan with custom data
Posted by Thomas Mueller <mu...@adobe.com>.
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" <ch...@gmail.com> 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
Re: Extending the IndexPlan with custom data
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Tue, Aug 19, 2014 at 11:59 AM, Marcel Reutegger <mr...@adobe.com> wrote:
> Maybe this is already sufficient for
> your requirement?
Yup that would serve the purpose. For now I do not require that
support after following Thomas suggestion about using one index per
implementation. So for multiple Lucene index defintions multiple
LuceneIndex instances would be returned by LucenIndexProvider and each
impl would return a single plan
Chetan Mehrotra
Re: Extending the IndexPlan with custom data
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
as part of OAK-1980 I recently extended the IndexPlan with additional
methods like getDefinition(). This method returns the NodeState of the
index definition and allows you to identify the associated index in
content when the plan is executed. Maybe this is already sufficient for
your requirement?
Regards
Marcel
On 31/07/14 12:57, "Chetan Mehrotra" <ch...@gmail.com> 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