[
https://issues.apache.org/jira/browse/LUCENE-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15507544#comment-15507544
]
Dawid Weiss commented on LUCENE-7453:
-------------------------------------
To me the difference between {{docnum}} and {{docid}} is really that {{docnum}}
is one letter longer :) Seriously, it doesn't seem to be explaining anything
more than {{docid}} does. It would be more self-explanatory to call it
{{segmentIndex}}, but this seems verbose.
Don't you think adding better documentation (in one place and linking to it)
would be a better idea than just renaming? Also, the nomenclature here has been
with us for years. I don't see an obvious benefit of switching to {{docnum}}
for new users and I see how it may be a confusing change to existing
Lucene-experienced developers (especially if they have their own code that
would stick to "docid" in local variables, etc.
> Change naming of variables/apis from docid to docnum
> ----------------------------------------------------
>
> Key: LUCENE-7453
> URL: https://issues.apache.org/jira/browse/LUCENE-7453
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Ryan Ernst
>
> In SOLR-9528 a suggestion was made to change {{docid}} to {{docnum}}. The
> reasoning for this is most notably that {{docid}} has a connotation about a
> persistent unique identifier (eg like {{_id}} in elasticsearch or {{id}} in
> solr), while {{docid}} in lucene is currently some local to a segment, and
> not comparable directly across segments.
> When I first started working on Lucene, I had this same confusion. {{docnum}}
> is a much better name for this transient, segment local identifier for a doc.
> Regardless of what solr wants to do in their api (eg keeping _docid_), I
> think we should switch the lucene apis and variable names to use docnum.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]