: Ideally, most of the info one needs to understand and query and index : would be in the schema.xml (hence it makes sense for copyField to be : there). Since this will affect the "language" of the query parser, it : can make sense to go in schema.xml : : But if a case were ever made for configuring this stuff per-request : handler, or if there were a more generic mechanism for the whole : default-in-request-handler-and-overridable-via-query pattern, then it : might make sense for solrconfig.xml
i have no strong opinion. my gut says that as it pertains to the "default" query parser, it makes sense in the schema -- just like the default field -- becuase the person building the schema and defining the fields knows what makes the most sense for querying it (ie: slop and fuzz factor). per-request-handler overrides obviously could exist in the solrconfig as part of the requestHandelr registry. I like to imagine that there are two personas involved in the creation of a solr instance -- the schema creator that understands the data intimately but has no knowledge of how people plan to use it (so he has to think in the most general terms that make sense for the data) and the solrconfig creator whose knows the clients and their expected usage patterns but isn't an expert on the source data. With that mindset, these kinds of request handler agnostic defaults seem to make sense in the schema.xml : Related: if someone were to take the time to understand the surround : query parser, where would it's config go? one would have to understand it to make the decision wouldn't one? baroque grammer aside: it really depends ... i would imagine the schema.xml (for the same reasons i mentioned above) but i don't really know enough about it to say. -Hoss
