ack, +1 on adding the attributes map. On Fri, Oct 10, 2014 at 11:15 AM, Chetan Mehrotra <chetan.mehro...@gmail.com > wrote:
> Hi Alex, > > After discussing it with Marcel offline I was thinking to add > attribute support to IndexPlan. Attached the patch implementing > following approach to OAK-2173 > > 1. Expose a method Object getAttribute(String name) > 2. Allow passing in a map to builder > > This would allow arbitrary payload attached to IndexPlan instance. > > If I go extension route then I would need to decorate an existing > IndexPlan instance so quite a bit of redundant code. So would prefer > an attribute based approach. > > Thoughts? > Chetan Mehrotra > > > On Fri, Oct 10, 2014 at 2:21 PM, Alex Parvulescu > <alex.parvule...@gmail.com> wrote: > > 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 < > chetan.mehro...@gmail.com> > > 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 > >> <chetan.mehro...@gmail.com> 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 > >> >
