TL:DR: it seems like DirectoryReader.getIndexCommit() returns weird
results when using a "reopened" reader off of uncommited IW changes.
Even though 2 diff readers will expose diff views of the index, they will
claim to refer to the same IndexCommit.
Slightly Longer Version...
The test below, if added to TestIndexWriterReader, will pass reliably
AFAICT -- but that seems really weird to me. Note in particular the
'nocommit' comments and the assertions that follow them -- these are very
diff readers, exposing very diff views of the index, yet they claim to
have the same "IndexCommit" & generation underpinning them, evne though
some of the details of their IndexCommits differ
This seems weird, and I'm wondering if it's a bug, or an undespecified
behavior (and we should beef up the docs to clarify what to expect), or if
it represents some "feature" whose value i'm not understanding?
public void testIndexCommitOfReaderAfterReopen() throws Exception {
final Directory dir = newDirectory();
final IndexWriterConfig iwc = new IndexWriterConfig(new
MockAnalyzer(random()));
final IndexWriter w = new IndexWriter(dir, iwc);
try {
final DirectoryReader r0 = DirectoryReader.open(w);
try {
assertEquals(0, r0.numDocs());
final IndexCommit c0 = r0.getIndexCommit();
assertEquals(0L, c0.getGeneration());
} finally {
r0.close();
}
w.addDocument(new Document());
w.commit();
final DirectoryReader r1 = DirectoryReader.open(w);
try {
assertEquals(1, r1.numDocs());
final IndexCommit c1 = r1.getIndexCommit();
assertEquals(1L, c1.getGeneration());
assertEquals(1, c1.getSegmentCount());
w.addDocument(new Document());
final DirectoryReader r2 = DirectoryReader.openIfChanged(r1, w, true);
try {
assertNotNull(r2);
assertFalse(r1.equals(r2));
assertEquals(2, r2.numDocs());
// nocommit: Why do the assertions pass?
//
// nocommit: If the readers are not the same, and refer to different
// nocommit: "point in time" views of the index, then shouldn't they
// nocommit: also return different 'getIndexCommit()' results?
//
// nocommit: Should the "realtime" reader return 'null' since it's
view
// nocommit: of the index is not represented by a tangible commit?
assertEquals(c1, r2.getIndexCommit());
assertEquals(1L, r2.getIndexCommit().getGeneration());
assertEquals(c1.getSegmentsFileName(),
r2.getIndexCommit().getSegmentsFileName());
// nocommit: particularly odd: even though the commits are ".equals()"
// nocommit: and have the same generation & segments file,
// nocommit: they have diff segment counts and files
assertEquals(2, r2.getIndexCommit().getSegmentCount());
assertTrue(!
c1.getFileNames().equals(r2.getIndexCommit().getFileNames()));
} finally {
r2.close();
}
} finally {
r1.close();
}
} finally {
w.close();
dir.close();
}
}
Backstory: I'm digging into the Solr snapshot/backup code with an
objective of fixing SOLR-13872, but before i move forward with changing
anything I want to make sure I backfill the existing snapshot/backup test
code with new test cases for all the code paths that seem underrepresented
in tests so i don't risk introducing new bugs. While trying to
understand/test/document how Solr behaves if a user tries to request a
snapshot/backup when using "softCommit" (at the solr level), I noticed
this weird behavior of getting the same IndexCommit back from the
reader even after we'd re-opened a Reader/Searcher w/o committing.
-Hoss
http://www.lucidworks.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
