shouldn't IndexReader.hasDeletions return numDeletedDocs() > 0 by default instead of being abstract?
I fell into this trap myself before (naively providing a fake livedocs to a filterreader), there are quite a few traps and inconsistencies:
- if you override the livedocs you currently need to override a bunch of other things too (e.g. hasDeletions, numDocs). we should at least add a javadoc to FilterAtomicReader make it less trappy.
- hasDeletions is abstract, and its easy to forget to implement this.
- SegmentReader says that for hasDeletions/numDocs/maxDoc "Don't call ensureOpen() here (it could affect performance)". But FilterAtomicReader only says this for numDocs and maxDoc and calls it on hasDeletions!
- default implementation in SegmentReader uses liveDocs != null: but i dont know anything checking (e.g. CheckIndex should do this) that the codec's LiveDocsFormat must return null (vs a Bits matching all docs). We should check this if there is code actually making this (undocumented) assumption.
For SegmentReader at least, it seems to be better if it had this implementation: and neither numDocs() and maxDocs() calls ensureOpen() either so I only see it as a safer way to go (we could avoid the sketchy liveDocs != null, but i bet other code elsewhere relies on this too).
isn't the default impl of TermsEnum.termState dangerous? Shouldn't it throw an UnsupportedOperationException or being abstract instead?
I don't know whats going on here: but I agree. it seems the current default implementation is "silently wont work".