I would go with #1, add a custom IndexPlan impl.
Half of the properties that we currently set in the index plan builder are
not going to change anyway (like #setIncludesNodeData, #setFulltextIndex)
so it makes sense to hide that away for conciseness.

alex


On Thu, Oct 9, 2014 at 1:17 PM, Chetan Mehrotra <[email protected]>
wrote:

> Just to add in that thread Marcel suggested to use the NodeState
> related to index definition [3]. This would work fine for property
> index which directly use that defintion. However currently we manage
> Lucene index (IndexSearcher) by path. Hence the need to access to
> index path details to obtain the right Lucene index
>
> Chetan Mehrotra
> [3] http://markmail.org/message/jjrkz7x7vwzunypa
>
>
> On Thu, Oct 9, 2014 at 4:40 PM, Chetan Mehrotra
> <[email protected]> wrote:
> > Hi,
> >
> > While working on Lucene property index support I need to modify the
> > logic to support multiple Lucene Index definitions. The approach used
> > in patch attached to OAK-2005 creates multiple LuceneIndex instances
> > which are bound to various Lucene index definitions [1].
> >
> > However as discussed in last Oakathon we also need to be prepared to
> > support index at non root node (OAK-1980). And for that it was
> > suggested to return multiple IndexPlans from within Index impl which
> > take into account index definition determined via path restriction.
> >
> > To do that later when actual query is to be performed I need to
> > corelated the IndexPlan with actual LuceneIndex. Current IndexTracker
> > tracks Lucene indexes via path. So I need to determine what index path
> > in repo given IndexPlan refers to. Similar thing was discussed
> > sometime back in [2].
> >
> > So any thoughts on what approach to take
> >
> > 1. Use a custom IndexPlan impl and add required meta info like index
> > path in that
> > 2. Have some way of passing a payload in the IndexPlan itself which an
> > index impl can use to manage such info
> >
> > Chetan Mehrotra
> > [1]
> https://github.com/chetanmeh/jackrabbit-oak/compare/chetanmeh:trunk...OAK-2005?diff=split#diff-12
> > [2] http://markmail.org/thread/jjrkz7x7vwzunypa
>

Reply via email to