[ 
https://issues.apache.org/jira/browse/LUCENE-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511042#comment-15511042
 ] 

Ryan Ernst commented on LUCENE-7453:
------------------------------------

bq. I don't like overloading index for this, especially in the class names, so 
for now I'd prefer the segment variants in second column.

But the seg examples you have still have docid, just with seg prepended. It 
still has the problem that it uses "id", when id means identifier, which is 
usually an opaque string. {{docnum}} to me is still the best, the document 
number in the segment (where "in the segment is implied", although if we want 
SegDocNum, I guess it'd be ok, just more wordy).

bq. Anyway, we could use the opportunity to shorten some of the longer names.

+1

> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to