FYI: with Yonik's latest commit (#1003107) the problem that Scott mentioned is no longer an issue – but the reason is that Yonik's changes severly limit the set of field names that can legally be sorted on to those that meat the same requirements as a java identifier (ie: "1_s" is no longer a field name that can be sorted on)
An idea that has been floating around in my head since i saw Scott's comment is that instead of trying to parse a field name first, and then doing function parsing second, we should reverse the order: try to parse as a function first, then as a field name (because we don't allow wild card style function names, but we do allow dynamic field names)
After looking at Yonik's commit, i brought this up with him on IRC and we came to a consensus that:
- we should discourage people from having crazy field names
- it might be expensive to try and parse every sort param as a function if it then turned out to be a simple field name - particularly since some FieldTypes might support SortField but not ValueSource (so trying to parse as a function first would likely result in an exception)
- we should optimize for the simple common case of simple field names
So with that in mind, i came up with the attached patch which leaves in the quick short circuit for field names that are really simple, then tries to parse as a function, then as a last resort uses the same basic parsing that Solr 1.4 did: treats everything up to the first whitespace as a potential field name.
Attached patch shows some new tests that it fixes (i also included some other test additions related to the general concept of localparams in the sort param to ensure i didn't break them)