Thanks Hoss,
This is starting to sound pretty complicated. Are you saying this is not
doable with Solr 4.10?
>>...or at least: that's how it *should* work :) makes me a bit nervous
about trying this on my own.
Should I open a JIRA issue or am I probably the only person with a use case
for replacing a TermIndexInterval setting with changing the min and max
block size on the 41 postings format?
Tom
On Tue, Jan 13, 2015 at 3:16 PM, Chris Hostetter <hossman_luc...@fucit.org>
wrote:
>
> : ...the nuts & bolts of it is that the PostingFormat baseclass should take
> : care of all the SPI "name" registration that you need based on what you
> : pass to the super() construction ... allthough now that i think about it,
> : i'm not sure how you'd go about specifying your own name for the
> : PostingFormat when also doing something like subclassing
> : Lucene41PostingsFormat ... there's no Lucene41PostingsFormat constructor
> : you can call from your subclass to override the name.
> :
> : not sure what the expectation is there in the java API.
>
> ok, so i talked this through with mikemccand on IRC...
>
> in 4x, the API is actaully really dangerous - you can subclass things like
> Lucene41PostingsFormat w/o overriding the name used in SPI, and might
> really screw things up as far as what class is used to read back your
> files later.
>
> in the 5.0 APIs, these non-abstract codec related classes are all final to
> prevent exactly this type of behavior - but you can still use the
> constructor args to change behavior related to *writing* the index, and
> the classes all are designed to be smart enough that when they are loaded
> by SPI at search time, they can make sense of what's on disk (regardlessof
> wether non-default constructor args were used at index time)
>
> but the question remains: where does that leave you as a solr user who
> wants to write a plugin, since Solr only allows you to configure the SPI
> name (no constructor args) via 'postingFormat="foo"'
>
> the anwser is that instead of writing a subclass, you would have to write
> a small proxy class, something like...
>
>
> public final class MyPfWrapper extends PostingFormat {
> PostingFormat pf = new Lucene50PostingsFormat(42, 99999);
> public MyPfWrapper() {
> super("MyPfWrapper");
> }
> public FieldsConsumer fieldsConsumer(SegmentWriteState state) throws
> IOException {
> return pf.fieldsConsumer(state);
> }
> public FieldsConsumer fieldsConsumer(SegmentWriteState state) throws
> IOException {
> return pf.fieldsConsumer(state);
> }
> public FieldsProducer fieldsProducer(SegmentReadState state) throws
> IOException {
> return pf.fieldsProducer(state);
> }
> }
>
> ..and then refer to it with postingFormat="MyPfWrapper"
>
> at index time, Solr will use SPI to find your "MyPfWrapper" class, which
> will delegate to an instance of Lucene50PostingsFormat constructed with
> the overriden constants, and then at query time the SegmentReader code
> paths will use SPI to find MyPfWrapper by name as well, and it will again
> delegate to Lucene50PostingsFormat for reading back the index.
>
>
> or at least: that's how it *should* work :)
>
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
