At 9:42 PM -0800 2/21/07, Chris Hostetter wrote:
>yeah ... the semantics discussed previously for backwards compatibility
>were...
>
> 1) if sort param, use it and do no special ; parsing
> 2) if no sort param, check for ; and extract sort
FWIW, in an in-progress refactoring of StandardRequestHandler and
DisMaxRequestHandler, I made (but did not have a chance to test) the following
trivial change:
// get sort specification, if any, from sort=<sort> param or ;<sort>
appended to query
Sort sort = U.getSort(req);
if( sort == null ) {
// legacy mode, where sreq is query;sort
List<String> commands = StrUtils.splitSmart(sreq,';');
qs = commands.size() >= 1 ? commands.get(0) : "";
if (commands.size() >= 2) {
QueryParsing.SortSpec sortSpec =
QueryParsing.parseSort(commands.get(1), req.getSchema());
if (sortSpec != null) {
sort = sortSpec.getSort();
}
}
}
>..but i'm wondering if we want an explicit param indicating that the old
>behavior should be supressed -- that way having no sort param can default
>to sort on score just like with dismax (and it won't break if the query
>happens to have a ; in it).
I agree that a user of the sort parameter wouldn't want their query string
munged as a side effect of not supplying sort, or setting it to blank, on some
request. But having an explicit parameter to control every aspect of legacy
behavior could certainly lead to nasty parameter bloat...
How about officially deprecating the ;sort behavior, bumping the current
version attribute to 2.3 or 2.5, and using that to control whether the
sort==null fork is chosen? I haven't been able to keep track of the zillions
of improvements in the past few weeks submitted by Ryan et alia, but perhaps
there are other API-busting changes which could benefit from being lumped into
a version bump?
The fly in the ointment is that in the sample solrconfig the example request
handlers have no version default (or it has been commented out). This is too
bad because it means that version-dependent code changes like this will break
for a person using an existing solrconfig e.g. customized from the sample. The
sample file really should set version explicitly in all RH definitions in order
to establish a contract with the user that the behavior it defines will not
change. Perhaps there should be a top-level solrconfig parameter setting a
global request-handler version default, and then the documentation could say
"you must set the version to > xxx either globally or on a per-handler or
per-request basis in order to use the following features" or vice-versa.
- J.J.
