lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject solr example != solr defaults
Date Thu, 09 Jun 2011 19:47:12 GMT

Trying to catch up on my email/jira, i notice this comment from rmuir in 

>> I think we need to stop kidding ourselves about example/default and 
>> just recognize that 99.99999999999% of users just use the example as 
>> their default configuration. Guys, the example is the default, there is 
>> simply not argument, this is the reality!

While i agree that we should recognize and expect solr users to start with 
the example configs and use them as their "default configs" under no 
circumstances should we get in the habit of refering to things specified 
in those configs "the default behavior" or "the default settings"

this isn't a question of kidding ourselves, it's a question of genuinely 
confusing users about the differnece between behavior that exists because 
of what is in the example configs that they may have copied and behavior 
that exists because of hardcoded defaults in java code.

Example #1: for backwards compatability, the "default" lockType used in 
solr when no <lockType/> declaration is found is "simple" but the 
*example* <lockType/> declared in the *example* configs is "native".

Example #2: Many request handler instances are declared/configured in the 
"example" solrconfig.xml file, but only 1 request handler instance will 
exist by *default* if the user removes those <requestHandler/> 
declarations from the solrconfig.xml

The point is: If you find yourself getting into the habit of refering to 
config values/settings in the example configs as "the defaults" then you 
*will* misslead users into thinking that you are describing the "default 
behavior" when those values/settings are absent from the configs.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message