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 >>
