After discussing it Tomomaso offline would be going with option #3. Opened OAK-2168 to track changes required in SolrIndex to support AdvanceQueryIndex and later AggregateIndex Chetan Mehrotra
On Wed, Oct 8, 2014 at 3:20 PM, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > Hi Tommaso, > >>also Solr doesn't support aggregation > Is it that Solr does not support it. Or it supports but not configured > to do so at runtime? > > Further there is a third option also of > > 3. Not wrapping the SolrIndex with AggregateIndex in test. > > With #3 all testcase pass for now I can move on with Lucene index > related work (OAK-2005). Would it be ok if I do #1 i.e. Make > SolrQueryIndex implement AdvanceQueryIndex and thus > AdvanceFulltextQueryIndex bit later. > > Thoughts? > Chetan Mehrotra > > > On Wed, Oct 8, 2014 at 3:12 PM, Tommaso Teofili > <tommaso.teof...@gmail.com> wrote: >> Hi Chetan, >> >> I think no. 1 is definitely the best, also Solr doesn't support aggregation >> at the moment, so it'd be a good change to do that. >> >> Regards, >> Tommaso >> >> >> 2014-10-08 11:17 GMT+02:00 Chetan Mehrotra <chetan.mehro...@gmail.com>: >> >>> For OAK-2119 I had modified AggregateIndex to implement >>> AdvanceQueryIndex. This was done with the assumption that it is only >>> used by LuceneIndex. However Solr testcase do check against >>> AggregateIndex (though it is not configured for that at runtime) and >>> they fail with this change >>> >>> Now I have two options >>> >>> 1. Make SolrQueryIndex implement AdvanceQueryIndex and thus >>> AdvanceFulltextQueryIndex >>> 2. OR Duplicate AggregateIndex to have one impl for AdvanceQueryIndex >>> and other for QueryIndex >>> >>> Doing #1 should not take much effort but still a change in existing impl. >>> >>> Which route to take? >>> >>> Chetan Mehrotra >>>
