: ...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/
