: Since SegmentInfos is now public, you could use SegmentInfos.read to : read the current segments_N file, and then call its .size() method? : : But, this will only count as of the last commit... which is probably : not sufficient for SOLR-1559?
Honestly: i have no idea, I'm a little out of touch with awhat "commit" means in Lucene-Java these days. The goal is to be able to compute a maxNumberOfSegments relative to "the current number of segments", some people might percieve that as the current number of "committed" segments -- but really it comes down to what optimize is going to do with the resulting number. if someone has the goal of making iterative micro optimizations to their index, so they say "optimize to $currentSegmentCount-1 segments" but the number of commited segments is 3 and the number of uncommited segments is 27 higher (because of active indexing) so the app starts trashing as it tries to optimize down from 27 to 3 that doesn't feel like "Do what i mean" : We could simply make getSegmentCount public / expert / not only for tests? I was considering doing that in the SolrIndexWriter class that already exists as a subclass of IndexWriter, but i didn't want to go that route if there was a good reason why IndexWriter.getSegmentCount isn't already public (ie: if there was an expecation that the way IndexWRiter manages segments was subject to refactoring getSegmentCount out of existence) -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
