: What's the usecase here, and the downside to having to provide the : full fq list in the URL? : Is this simply to shorten the request URLs?
The main use case is to allow configuration of a requestHandler that the clients don't have to be aware of at all it "just works" ... in the case of "fq" it can be for partitioning the index as opposed to filtering down the results from user options. (ie: a requestHandler with a permanent "fq=inStock:true" which the client can be ignorant of when adding additional "fq" params based on user selected facets to filter on like price and color) FQ is hte biggest example, but the same mentality could applied to other multivalue params. Imagine if we make the "bf" param of dismax multivalue (it was allways intended to be but SolrQueryRequest didn't suport that when i wrote it and i haven't quite figured out hte best backwards compatible way to change it now) you could configure a hardcoded boost on "date" to reflect a biz logic bias for "newer" documents you want to instill in the results, and the client could allow users to specify additional boosts based on functions of price, or size, etc -- without the client needing to even be aware of the orriginal "date" boost function. You could think of it as just shortening the URLs, but we're finding that in practice it's more important then that. As it stands now the front end clients have to be completely aware of the current requestHandler configs in order to "add" to them -- which means either that information needs to be on the server and in the client, or it only lives in the client (but now any new client has to know about that rule as well), or the clients need to use debugQuery=1 and parse the info about which filter queries are currently being applied. : Of course once you make it so that something is always appended, that : will annoy someone else who wants to completely override it :-) True -- but that becomes a decision the person defining the configs can make. If they want it to be overridable they put it in a "defaults" list as they can now, if they want it to allways be appended to the query params they can put it in a (new) seperate list. It gives the person configuring the server the ability to say "for each requestHandler: these things can be overriden, these things can be added to (and possibly: these things are fixed and can not be modified by the client) : An alternative is to provide some sort of syntactic support for : specifying the append operation rather than the overwrite operation : w.r.t. defaults. : : fq+=color:red : : I'm not sure how hard it would be to support that exact syntax w/ : SolrParams and HttpServletRequest though. ignoring the issues of URL escaping and what exactly it would look like, something that would allways be possible if we add a method to SolrParams get all param names (HttpServletRequest already has this) but it puts the power in the hands of the client generating the request -- what i'm suggesting is putting more power in the hands of the people configuring the index. There's certainly no reason we can't do both -- what you're describing would just affect the relationship of the request params with the <lst name="defaults"> when they get bundled into a DefaultSolrParams; what i'm describing would be the relationsihp between *that* set of params and a new "<lst name="appended"> set. -Hoss
