Dear list,
I'd like to bounce on that issue...
IMHO, configuration parsing could be a little bit stricter... At least,
what stands for a "severe" configuration error could be user-defined.
Let me give some examples that are common errors and that don't trigger
the "abortOnConfigurationError" behaviour, while it's set to true.
* In schema.xml, one can set the attribute multivalued="true" or
multiValude="true", and that won't trigger any startup error.
* In solrconfig.xml, it's even possible to declare configuration objects
(such as fragListBuilder nodes) although solr 1.4 doesn't know anything
about such a thing.
I've experienced both worlds in my short life : strict configuration
parsers which get really painful to maintain when configuration becomes
complex, and loose parsers which are so nice with configuration errors
that sometimes a simple typo error gets hard to be spotted out (even if
the multivalued="true" error is usually easy to find, as soon as one
adds several values to a non multi-valued field :), the highlighting
issue requires people to pay more attention to the "/!\ SolrX.Y"
mentions on the wiki... BTW, http://wiki.apache.org/solr/Solr3.5's
content seems outdated, I think it was released a month ago or so...
Kudos! ;-) )
The point here is that, from my point of view, the
abortOnConfigurationError flag is actually of little help when playing
around with the configuration (at least without the ability to define
what a severe configuration error is)
Thank you for your attention!
--
Tanguy
Le 28/12/2011 09:43, Koji Sekiguchi a écrit :
(11/12/28 17:08), Ahmet Arslan wrote:
FastVectorHighlighter requires Solr3.1
http://wiki.apache.org/solr/HighlightingParameters#hl.useFastVectorHighlighter
Right. In addition, baoundaryScanner requires 3.5.
koji
