[
https://issues.apache.org/jira/browse/LUCENE-9616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235072#comment-17235072
]
Julie Tibshirani edited comment on LUCENE-9616 at 11/19/20, 12:07 AM:
----------------------------------------------------------------------
I also suspect it's enough to keep unit tests for old formats. And maybe this
could only be forward-looking -- we would make sure to preserve tests in future
changes, but not actively add logic/ tests back?
bq. I gave it a try on my PR for LUCENE-9613 by keeping the old
DocValuesConsumer around
Thanks for trying out the idea. It looks like you copied all logic for version
1 of Lucene80DocValuesConsumer into a test class Lucene80v1DocValuesConsumer. I
guess an alternate naming scheme would be to rename the current
Lucene80DocValuesConsumer -> Lucene88DocValuesConsumer, and name the test class
Lucene80DocValuesConsumer (instead of Lucene80v1DocValuesConsumer). I liked
that this doesn't introduce a new version element, but it might be confusing
that the producer/ consumer versions no longer align. Also should these tests
live in backwards-codecs instead of core?
was (Author: jtibshirani):
I also suspect it's enough to keep unit tests for old formats. And maybe this
could only be forward-looking -- we would make sure to preserve tests in future
changes, but not actively add logic/ tests back?
bq. I gave it a try on my PR for LUCENE-9613 by keeping the old
DocValuesConsumer around
Thanks for trying out the idea. It looks like you copied all logic for version
1 of Lucene80DocValuesConsumer into a test class Lucene80v1DocValuesConsumer. I
guess an alternate naming scheme would be to rename the current
Lucene80DocValuesConsumer -> Lucene87DocValuesConsumer, and name the test class
Lucene80DocValuesConsumer (instead of Lucene80v1DocValuesConsumer). I liked
that this doesn't introduce a new version element, but it might be confusing
that the producer/ consumer versions no longer align. Also should these tests
live in backwards-codecs instead of core?
> Improve test coverage for internal format versions
> --------------------------------------------------
>
> Key: LUCENE-9616
> URL: https://issues.apache.org/jira/browse/LUCENE-9616
> Project: Lucene - Core
> Issue Type: Test
> Reporter: Julie Tibshirani
> Priority: Minor
>
> Some formats use an internal versioning system -- for example
> {{CompressingStoredFieldsFormat}} maintains older logic for reading an
> on-heap fields index. Because we always allow reading segments from the
> current + previous major version, some users still rely on the read-side
> logic of older internal versions.
> Although the older version logic is covered by
> {{TestBackwardsCompatibility}}, it looks like it's not exercised in unit
> tests. Older versions aren't "in rotation" when choosing a random codec for
> tests. They also don't have dedicated unit tests as we have for separate
> older formats, for example {{TestLucene60PointsFormat}}.
> It could be good to improve unit test coverage for the older versions, since
> they're in active use. A downside is that it's not straightforward to add
> unit tests, since we tend to just change/ delete the old write-side logic as
> we bump internal versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
