[
https://issues.apache.org/jira/browse/SOLR-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15501376#comment-15501376
]
Yonik Seeley commented on SOLR-9528:
------------------------------------
bq. I'm not a fan of allowing docid to be used as input to a query without a
compelling real-world use-case.
We already do though... one can do "sort=_docid_ asc"
To not totally be confused by that, one must understand what _docid_ is (and
that it can change across commits).
So in my view, it's not a matter of adding a new magic field, but just making
the exisitng one more consistent. If you can sort by it, and retrieve it, let
one query by it as well.
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
