lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3226) rename SegmentInfos.FORMAT_3_1 and improve description in CheckIndex
Date Thu, 23 Jun 2011 12:20:47 GMT


Michael McCandless commented on LUCENE-3226:

bq. What is the benefit of naming the constant according to what has changed?

Because then devs trying to work w/ the code have some sense of what the change was?  EG for
debugging maybe it's helpful, eg if something has gone wrong, later, in how SegmentInfos is
handling that version or what not.

bq.  And what if two changes occur in the same release?

Well, we can handle that case by case?  I agree it's messy... maybe pick a name describing/subsuming
both?  Or favor one name (maybe the "bigger change") and use comments to explain the other
But if there is a comment/comments above the constant containing this same information that's
just as good...

bq. These constants, IMO, are used only to detect code that is needed to support a certain
version, and nothing more.

Right, but for the devs that need to revisit such code, it's helpful to know what "real" change
occurred within that version... else, during debugging they'd have to eg go do some svn archaeology
to understand the change.

bq. And since the purpose of LUCENE-2921 is to move all index format tracking to be at the
'code'-level and not 'feature'-level, I'd assume the constants would be named accordingly.

True... so maybe we take this up under that issue?  I would be OK with just having comments
that describe what changed in each version...

So for this issue maybe re-commit just the CheckIndex fix, and leave the constant naming fixes
to LUCENE-2921?

> rename SegmentInfos.FORMAT_3_1 and improve description in CheckIndex
> --------------------------------------------------------------------
>                 Key: LUCENE-3226
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 3.1, 3.2
>            Reporter: Hoss Man
>             Fix For: 3.3, 4.0
>         Attachments: LUCENE-3226.patch
> A 3.2 user recently asked if something was wrong because CheckIndex was reporting his
(newly built) index version as...
> {noformat}
> Segments file=segments_or numSegments=1 version=FORMAT_3_1 [Lucene 3.1]
> {noformat}
> It seems like there are two very confusing pieces of information here...
> 1) the variable name of SegmentInfos.FORMAT_3_1 seems like poor choice.  All other FORMAT_*
constants in SegmentInfos are descriptive of the actual change made, and not specific to the
version when they were introduced.
> 2) whatever the name of the FORMAT_* variable, CheckIndex is labeling it "Lucene 3.1",
which is missleading since that format is alwasy used in 3.2 (and probably 3.3, etc...). 

> I suggest:
> a) rename FORMAT_3_1 to something like "FORMAT_SEGMENT_RECORDS_VERSION"
> b) change CheckIndex so that the label for the "newest" format always ends with " and
later" (ie: "Lucene 3.1 and later") so when we release versions w/o a format change we don't
have to remember to manual list them in CheckIndex.  when we *do* make format changes and
update CheckIndex " and later" can be replaced with " to X.Y" and the new format can be added

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message