On 7/21/06, Andrew May <[EMAIL PROTECTED]> wrote:
I guess what it comes down to is that we need a clear specification of whether there are going to be namespaces or something similar in query parameters, and also how per-field query parameters should look. And then how this maps to configuration in solrconfig.xml and how that is stored and accessed in the code.We could take something like "." in a query parameter name to be equivalent to nested lists in solrconfig.xml, so "foo.bar.fubar=..." on the query string is comparable to <lst name="foo"> <lst name="bar"> <str name="fubar">...</str> </lst> </lst> But if you also use "." as a way of introducing grouping between properties, then you could get a lot of nesting - e.g. specifying the pre tag for a simple formatter for the title field might be "f.title.hl.simple.pre=<em>" which is a bit more nesting than I'd be comfortable with (or am prepared to type out!). If instead we separated on ":" and used "." just as part of a naming convention, then "f:title:hl.simple.pre=<em>" would be equivalent to: <lst name="f"> <lst name="title"> <str name="hl.simple.pre"><em></str> </lst> </lst> If something is specified globally, there's no wildcards, just a top level property. How does that sound?
Most of the time, config won't be per-field, so that should be kept simple (so I agree with the no wildcards part). I'm not sure I like the mix of ':' and '.', but we could just leave everything as '.' and special case per-field overrides so that the XML looks like what you have above. The other alternative is just to collapse everything: <name="hl.fragsize"> <name="f.title.hl.fragsize"> A one-to-one mapping of queryargs to solrconfig.xml params also has it's bonuses of being easier to explain to people. Anyway, thanks for your input! I know this has widened in scope and gotten a little off the path of what you were trying to achieve. The difficulties lie in Solr's configuration growing pains. (Spring or HiveMind Solr 2.0 anyone ;-) -Yonik
