: I've seen several Solr developers mention the fact that people often : copy example/ to become their solr installation and that that is not : recommended. We are rebuilding our search functionality to use Solr and : will be deploying it in a few weeks.
do you have specific examples from the mailing list of the recomendations you are seeing? in my opinion there's nothing wrong with copying the solr example to use as the basis for your own configs -- that's why it's there. Where people tend to run into problems (in my opinion) is... a) they never change the configs. those configs are examples. they showcase features, and the comments suggest best practices. that doesn't mean you need to shoe-horn your data into the declared fields, it doesn't mean you *have* to use dynamic fields in order to add a field with a new name. you should feel free to customize the configs to meet your needs. b) they assume that when upgrading, they should through out their old configs, and copy the newer examples configs. you should by all means *consult* the new configs, because there may be new features in there that you should consider, or new comments suggesting new best-practices, but if you completley throw out your old configs you *have* to reindex. some people either don't realize that and are suprised when they get weird errors, or take it for granted that they should *always* reindex even though it isn't neccessary. My advice: when starting a new collection "from scratch": base the configs on the example from the current version of solr you ar using, and customize. when upgrading solr: consult the new example config, and cut/paste anything you think you would like to have into your existing configs, considering the implications of reindexing (ie: changing field types). when adding a new collection to an existing installation: decide if it's really differnet from what you've already got, in which case base the configs off of the current example; or if it's similar to some collection you already have, base the configs off of those. : What about maintaining it? For example, Is it wise to up the : luceneMatchVersion and re-index with every upgrade? When new only if you have read the CHANGES.txt and feel like there is something about hte new features or modified behavior that suggests to you that you want those changes -- if you are happy with the existing behavior, leave it alone. The flip side is that if for some reason you decide you need to re-index everything, then you should consider bumping the luceneMatchVersion up to get what is now considered the "correct" behavior of those classes -- but just like upgrading, you should test these behavior hcanges and verify they are really what you want. -Hoss
