: I understand that this might seem as a simplification to users, where they : set this value once and it controls both places, but I think it's bad. : First, because if you set <useCompoundFile>, you basically *always* end up : w/ CFS, even if you intend that to apply to only newly flushed segments. In : order to use default settings for merged segments, you have to explicitly : include the default settings in the <mergePolicy> element. This is trappy I : think and looks odd.
I'm pretty sure this was intentional because it kept things consistent from a backcompat standpoint, and (for solr users with a high level understanding, not folks like you who are intimitly familiar with the underlying code) it's very easy to understand: if you just set <useCompoundFile/> -- w/o customizing a <mergePolicy/> -- all of your files are compound. Novice solr users will never be confused why there are some files that aren't compound. Having said that: times change. If you think it's trappy behavior for the common case, i won't agrue with you (somebody else might though). There's nothing to stop us from changing it, as long as we have a note in the Upgrading section making it clear what folks need to add to their solrconfig.xml file to maintain existing behavior if they so choose. (and as you said: beefing up the ref guide with details about why there are multiple CFS related settings, and ow they impact perf in different scenerios, etc...) : Beyond that, SolrIndexConfig is trunk contains deprecated code around this : parameter and somewhat hacks around older schemas that defined useCFS : inside the MP element -- are we still required to support that back-compat : in trunk as well? that's more of a judgement call. usually what we've done in situations like this is make the backcompat support log a WARN that the syntax they are using is deprecated and should be changed, but then we also tend to leave the support in for as long as feasible -- following the princible of "don't break shit for existing users unless absolutely neccessary". but "feasible" and "absolutely neccessary" can vary by situation: if the backcompat hoops we have to jump through are making the code impossible to maintain, or impossible to add some new feature, or causing performance problems for the common case (but that's rare with config still backcompat like we're talking about here) - then go ahead and rip it out in trunk; but when doing that we also usually update the "active" (ie: 4x) branch to switch those WARN logs to hard fails so they don't get overlooked by obtuse users who keep upgrading. So, for example: some user has a config file they've been upgrading since Solr 1.2 that contains a <foo/> tag. in 3.6 the syntax changed, <bar foo=""/> is the new right way to do things and we added backcompat kludge for the old syntax, with a WARN log advising them to change -- but the user never notices it. ~ 4.5 we decided the backcompat logic is getting to be a bitch to maintain, so on trunk we rip it out, but on 4x we add a special check that throws a hard starup error if the <foo/> tag was found in the config -- so as long as the guy upgrades to 4.6 at some point, he'll know beyond a doubt that he needs to change his config. but if he manages to upgrade from 4.5 directly to 5.x, then his antique syntax will just be silently ignored. -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
