Hello Jan Høydahl
Thank you very much for your comments.
Have uploaded new version of the patch.
Perhaps this property should be moved to some other Lucene class as a common global name for context field for all analyzers that supports context filtering,...
I agree and I moved CONTEXTS_FIELD_NAME into Lucene's Lookup.java, meaning that it is now available to all Lookup implemetations.
Regarding a request including suggesters that do not support filtering, I think it depends on its data whether the correct thing is to return an unfiltered response (open data) or to return nothing (sensitive data). Of course, the application has the power to pass suggest.dictionary accordingly if it knows that filtering is done. Alternatively, some suggest.returnUnFilteredSuggestionsIfFilteringIsNotSupported param to control it, I don't know...
Not quite sure about this:
Let's take the current solr 5.2.1:
passing suggest.q=term&suggest.contestFilterQuery=ctx1 will return all suggestions matching the term ignoring ctx1 as context filtering is not yet implemented.
I believe that keeping that behaviour for Lucene Suggesters that have not yet implemented context makes more sense to me.
In case a user need context filtering to happen on a Lucene suggester not yet supporting filtering, they just need to implement it.
Ideally and eventually, we will have context support for all Lucene suggesters, so I am not quite sure whether suggest.returnUnFilteredSuggestionsIfFilteringIsNotSupported is the way we should go.
I think that if CONTEXT_ANALYZER_FIELD_TYPE is explicitly given and wrong, we should fail-fast and throw exception instead of falling back to DocumentDictionaryFactory.CONTEXT_FIELD
I had thought a bit more about this.
I believe that we do not really need the CONTEXT_ANALYZER_FIELD_TYPE config.
One just needs to configure the context field in schema.xml with the needed query and index analyzers and all should work.
In case one needs different context analyzers for different suggesters, we just need to configure different context fields in schema.xml.
This has several advantages:
- Simpler/less configuration.
- Cleaner/more readable/less code to maintain.
In case I am missing any use-case, please let me know
Will let others chime in on the param names too. Which one do you like the best?
The param name is this latest patch is still suggest.contextFilterQuery as we have not agreed yet on the right name to adopt.
Maybe Robert Muir or Shalin Shekhar Mangar or Varun Thacker could help here