[
https://issues.apache.org/jira/browse/SOLR-6560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-6560.
----------------------------
Resolution: Fixed
Fix Version/s: Trunk
thanks tom,
i think we're good to go in 5.0
> Solr example file has outdated termIndexInterval entry
> ------------------------------------------------------
>
> Key: SOLR-6560
> URL: https://issues.apache.org/jira/browse/SOLR-6560
> Project: Solr
> Issue Type: Bug
> Components: documentation
> Affects Versions: 4.10
> Reporter: Tom Burton-West
> Assignee: Hoss Man
> Priority: Minor
> Fix For: 5.0, Trunk
>
> Attachments: CHANGES.SOLR-4136.patch, SOLR-6560.patch, SOLR-6560.patch
>
>
> The termIndexInterval comment and example settings in the example
> solrconfig.xml file is left over from Solr 3.x versions. It does not apply
> to the default Solr 4.x installation and its presence in the example is
> confusing.
> According to the JavaDocs for IndexWriterConfig, the Lucene level
> implementations of setTermIndexInterval and setReaderTermsIndexDivisor these
> do not apply to the default Solr4 PostingsFormat implementation.
> From
> (http://lucene.apache.org/core/4_10_0/core/org/apache/lucene/index/IndexWriterConfig.html#setTermIndexInterval%28int%29
> )
> "This parameter does not apply to all PostingsFormat implementations,
> including the default one in this release. It only makes sense for term
> indexes that are implemented as a fixed gap between terms. For example,
> Lucene41PostingsFormat implements the term index instead based upon how terms
> share prefixes. To configure its parameters (the minimum and maximum size for
> a block), you would instead use
> Lucene41PostingsFormat.Lucene41PostingsFormat(int, int). which can also be
> configured on a per-field basis:"
> The (soon to be ) attached patch just removes the outdated example.
> Documentation on the wiki and Solr ref guide should also be updated.
> Since the Solr 4 default postingsformat is so much more efficient than Solr
> 3.x, there might no longer be a use case for messing with the parameters.
> for users who have a strong _need_ to explicitly control this type of
> setting, you'll need to do so by overridding the default codec -- either by
> specifing a custom {{<codecFactory>}}, or by using the default
> {{SchemaCodecFactory}}, but specify per-field {{postingsFormats}} )(for the
> fields you want to modify) using custom classes -- for example: that subclass
> {{Lucene41PostingsFormat}} using the desired values...
> https://lucene.apache.org/solr/4_10_2/solr-core/org/apache/solr/core/CodecFactory.html
> https://lucene.apache.org/solr/4_10_2/solr-core/org/apache/solr/core/SchemaCodecFactory.html
> https://lucene.apache.org/core/4_10_2/core/org/apache/lucene/codecs/lucene41/Lucene41PostingsFormat.html#Lucene41PostingsFormat(int,%20int)
> https://cwiki.apache.org/confluence/display/solr/Field+Type+Definitions+and+Properties#FieldTypeDefinitionsandProperties-GeneralProperties
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
