Hoss Man commented on SOLR-9528:

bq. That works for many contexts, except perhaps Alex's original usecase: fetch 
me the document that corresponds to a specific \_docid\_ .

Ah, ok see -- i'm glad i asked: that usecase ("search for a document using it's 
internal id") was not actaully mentioned anywhere in this issue.

I would argue that we should few that as a broader problem (in a distinct 
jira): "make it less to find documents that have a specific function value" 
(ie: add a new qparser/syntaxtic sugar for the behavior frange where the 
low/high values are the same ... maybe...
q={!func eq=123456789}docid()

> 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