[
https://issues.apache.org/jira/browse/SOLR-14396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17078602#comment-17078602
]
David Smiley commented on SOLR-14396:
-------------------------------------
Woah; I think it's bad this throws an exception on an empty index -- no need to
convince me of that. I can see why I added this to begin with, however --
imagine you typo a dynamic field or something like that. Still, that scenario
is not specific to the tagger; doing plain old search on a field with no data
does not and should not result in warnings or errors. We don't need a
back-compat parameter to toggle this.
It'd be useful during Solr development / ad-hoc queries if Solr had a response
header notice that informed you that certain fields used by the request have no
data. That'd be useful Solr-wide, not just specifically this handler, but also
a pain to do as I think about it. Hmm.
> TaggerRequestHandler Should Not Error on Empty Collection
> ---------------------------------------------------------
>
> Key: SOLR-14396
> URL: https://issues.apache.org/jira/browse/SOLR-14396
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Trey Grainger
> Priority: Minor
>
> The TaggerRequestHandler (added in SOLR-12376) currently returns a 400 (Bad
> Request) if used on a collection with no terms in the index. This probably
> made sense for the use cases for which it was originally written (in the
> OpenSextant project, before it was contributed to Solr) that focused on on
> stand-alone document tagging, where the calling application expected there to
> always be an index.
> More and more use cases are emerging for using the TaggerRequestHandler in
> real-time for user queries, however. For example, real-time phrase matching
> and entity resolution in queries. In these cases, the data in the tagger
> collection may be dynamically updated, and at times, the collection may even
> be empty.
> While it's certainly possible for the 400 error to be handled client-side for
> empty collections, the incoming requests aren't really "bad" requests in my
> opinion, the index just doesn't have any data yet. Sending the same request
> subsequently once some documents are indexed would result in a success.
> I'm proposing we remove the exception for empty indexes and simply return no
> matched tags instead.
> If it's important for anyone to preserve the current behavior, we could add a
> parameter "errorOnEmptyCollection". Does anyone think preserving the error
> here is needed? What say you [~dsmiley]?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
