The Solr codec factory simply uses the Solr schema to fetch the desired
postings format name., because Lucene knows nothing about the Solr schema.
That postings format name is the name of a Lucene-level codec.

The name attribute of the <codecFactory> element is simply ignored. In
fact, the example solrconfig <codecFactory> element simply describes the
default codec factory for Solr and is unneeded - it's simply there for
documentation, and in case some advanced expert user wanted to override it.

-- Jack Krupansky

On Tue, Feb 10, 2015 at 8:54 PM, Shawn Heisey <apa...@elyograg.org> wrote:

> On 2/10/2015 3:23 PM, Benson Margulies wrote:
> > http://wiki.apache.org/solr/SimpleTextCodecExample
> >
> > Why does it have:
> >
> > <codecFactory name="CodecFactory" class="solr.SchemaCodecFactory" />
> >
> > and then:
> >
> > postingsFormat="SimpleText"
> >
> > Shouldn't the postingFormat match the codec factory name? For that
> > matter, how much of this is obsolete? Is there better doc elsewhere or
> > does this need help?
>
> If I am wrong about this, then I can plead ignorance, but from what I
> can see, I don't think that the codecFactory and postingsFormat should
> match.  A codecFactory seems to be designed to select and manipulate the
> Lucene codec that ultimately gets used for the index, while
> postingsFormat looks like it's only one small part of a Lucene codec
> definition -- and one of the things that can be manipulated by the
> codecFactory.
>
> The code in SchemaCodecFactory is very short and deceptively simple,
> leveraging a great deal of functionality from other classes.  If I'm
> reading it right, that class is required in order for the postingsFormat
> and docValuesFormat options in the schema to actually take effect.  If
> that codecFactory is not explicitly specified in the schema, those
> configs would probably be ignored.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Reply via email to