[
https://issues.apache.org/jira/browse/SOLR-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15505121#comment-15505121
]
Hoss Man commented on SOLR-9528:
--------------------------------
I don't understand, practially/actionable, what this sentence means...
{noformat}
...proposed that _docid_ should be a legitimate pseudo-field, which would
make it returnable, usable in function queries, etc.
{noformat}
* How is (anyone) defining "legitimate pseudo-field" in this context?
* There's not enough context to understand what is implied by the "etc." in
this sentence -- what are some concrete examples of what users would be able to
do in the future that they can't do now
** alternatively: what are some examples of existing vs new _syntax_ that is
being proposed (either in configs or requests) for functionality that is
already supported?
----
If the crux of this idea here is simply that the string {{\_docid\_}} should be
usable anywhere that a fieldname can be used even when it's not defined in the
schema, then that seems like a particularly bad/inconsistent idea to me since
all of the other magic {{\_underscore\_}} fields that exist in solr *are*
definied in the schema, and it's actually important how/if they are stored,
docValues, etc...
I've never been a huge fan of *any* magic field names in solr, and I
*personally* would be confused as hell if we started doing encouraging users to
use magic field names that look like real field names but don't actually exist
-- especailly because i would never be sure when a user is asking a question if
they actually added {{\_docid\_}} to their schema -- a situation i have
actaully encountered in real live and was then *VERY* confused by the described
behavior of {{sort=\_docid\_ asc}}.
My straw man proposal would be to (informally/formally) deprecate using
{{\_docid\_}} in the sort param, and insitead offer a {{docid()}} (or
{{docnum()}}, whatever folks prefer) ValueSourceParser out of the box, that
people could pass to other functions (for the purpose of filtering, sorting,
whatever...), or request in the response via {{fl}} etc...
Special syntax like {{\_docid\_}} in the sort param made sense in the early
days of Solr, but feel hackish now that we have first order functions (which
are clearly a "computed" value, with no ambiguity that it might be stored)
(for that matter, i would argue we should do the same thing with "{{score}}" =>
{{score()}}, and add a {{random(seed)}} to replace the way users currently have
to configure solr.RandomField ... but i'll save those fights for different
jiras)
> 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, [[email protected]] 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: [email protected]
For additional commands, e-mail: [email protected]
