Erick Erickson commented on SOLR-9528:

The point about debugging is very well taken. Would that functionality be 
served by having the debug information return the internal Lucene doc ID? That 
would make it less tempting to use as _input_...

At first  blush though, I'm not a fan of allowing _docid_ to be used as _input_ 
to a query without a compelling real-world use-case. Partly I don't want to 
deal with "query responses differ when using the same ID" questions and having 
to unravel "Oh, you mean the internal ID, not the <uniqueKey>" ;). Allowing 
_docid_ to be an _output_ is fine IMO. This isn't a super-strong objection but 
I would like to see the practical application (not theoretical, one someone is 
actually using in the field) before going down this path though.

> Make _docid_ (lucene id) a pseudo field
> ---------------------------------------
>                 Key: SOLR-9528
>                 URL: https://issues.apache.org/jira/browse/SOLR-9528
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>    Affects Versions: master (7.0)
>            Reporter: Alexandre Rafalovitch
>            Priority: Minor
> Lucene document id is a transitory id that cannot be relied on as it can 
> change on document updates, etc.
> However, there are circumstances where it could be useful to use it in a 
> search. The primarily use is a debugging where some error messages provide 
> only lucene document id as the reference. For example:
> {noformat}
> child query must only match non-parent docs, but parent docID=38200 matched 
> childScorer=class org.apache.lucene.search.DisjunctionSumScorer
> {noformat}
> We already expose the lucene id with \[docid] transformer with \_docid_ 
> sorting.
> On the email list, [~yo...@apache.org] proposed that _docid_ should be a 
> legitimate pseudo-field, which would make it returnable, usable in function 
> queries, etc.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to