On 1 April 2014 15:23, Robert Muir <[email protected]> wrote:
> It is actually possible in lucene 4, but there is nothing really > convenient setup to do this. > > You have two choices there: > 1. trigger a massive merge (essentially an optimize), by wrapping all > readers and calling IndexWriter.addIndexes(Reader...). > 2. wrap readers in a custom merge policy and do it slowly over time. > > in both cases you'd use something like > > http://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/index/FieldFilterAtomicReader.java > > for lucene 3, this would be more complicated, I don't think its > impossible but there is no available code unfortunately in this case. > > Thanks Robert for the reply, all of that sounds fairly hairy. I did try a full optimize of the shard index using Luke, but the residual über-segment still has the filed definitions in it. Are saying in (1) that the creating of a new Shard index through a custom call to IndexWriter.addIndexes(..) would produce a _fully_ optimized index without the fields, and that is different than what an Optimize operation through ES would call? More a technical question now on what the differences is between the Optimize call and a manual create-new-index-from-multiple-readers. (I actually though that's what the Optimize does in practical terms, but there's obviously more or less going on under the hood under these different code paths). We're going the reindex route for now, was just hoping there was some special trick we could do a little easier than the above. :) thanks again for your time! Paul -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHfYWB7rg6R8-B4BeJxe%2BbCJvMdJPXwVev0Udd%3DB91kc6E6uGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
