[
https://issues.apache.org/jira/browse/SOLR-10832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-10832:
----------------------------
Attachment: SOLR-10832.patch
I started looking into writting a test for this and noticed we already have a
VersionInfoTest that purports to {{testMaxIndexedVersionFromIndex}} and
{{testMaxDocValuesVersionFromIndex}} -- but for some reason this test didn't
fail on my jira/SOLR-10807 branch (even though some CdCr tests, which use
{{VersionInfo.getMaxVersionFromIndex}}, did)
Digging in a bit I realized this tests is very misleading: all it currently
does is use {{UpdateLog.getMaxVersionFromIndex()}} which is essentially just a
wrapper around {{seedBucketsWithHighestVersion}} that does use
{{VersionInfo.getMaxVersionFromIndex}} _but also looks at the max version from
{{RecentUpdates}} *AND* from seeding a new clock if both are 0!_
In addition: the assertions made about the versions returned makes the test
useless for finding this kind of bug: where
{{VersionInfo.getMaxVersionFromIndex}} always returns null.
In the attached patch, I first beefed up the meat of the test to actually
differentiate between the expected "maxVersionFromUlog" and "vInfoMax" in the
case of committed & uncommited docs -- and verified this new test logic passes
with Trie fields. I then updated the 2 schema files used by this test to
randomize in point fields, so {{testMaxDocValuesVersionFromIndex}} now fails
50% of the time, or you can force it with
{{-Dsolr.tests.preferPointFields=true}}.
Before I spend time trying to actaully fix this bug, it would be nice if
someone could please sanity check: does these test changes make sense?
([~thelabdude] -- you wrote this baby, am i misunderstanding anything about
it's intent? any concerns with these changes so far?)
> Using "indexed" PointField for _version_ breaks
> VersionInfo.getMaxVersionFromIndex
> ----------------------------------------------------------------------------------
>
> Key: SOLR-10832
> URL: https://issues.apache.org/jira/browse/SOLR-10832
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Attachments: SOLR-10832.patch
>
>
> If someone configures {{\_version_}} using a {{LongPointField}} which is
> {{indexed="true"}} then {{VersionInfo.getMaxVersionFromIndex()}} will
> incorrectly assume...
> {code}
> // if indexed, then we have terms to get the max from
> if (versionField.indexed()) {
> LeafReader leafReader =
> SlowCompositeReaderWrapper.wrap(searcher.getIndexReader());
> Terms versionTerms = leafReader.terms(versionFieldName);
> Long max = (versionTerms != null) ?
> LegacyNumericUtils.getMaxLong(versionTerms) : null;
> {code}
> ...which will not work because Point based fields have no Terms.
> potential work around: configuring {{\_version_}} to use {{indexed="false"
> docValues="true"}} should cause this branch to be skipped and the existing
> ValueSource/DocValues based fallback to be used.
> We should either:
> * figure out if an alternative option exists for determining the "max" value
> of a LongPointField, and if so use that if {{versionField.indexed() &&
> versionField.getType().isPointField()}}
> * change {{VersionInfo.getAndCheckVersionField()}} to check if the version
> field {{IsPointField()}} and if so error unless {{indexed="false" &&
> docValues="true"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
