You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Julie Tibshirani (Jira)" <ji...@apache.org> on 2020/11/19 00:08:00 UTC
[jira] [Comment Edited] (LUCENE-9616) Improve test coverage for
internal format versions
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org