Currently, we don't allow sorting on multi-valued or fulltext fields at all, preventing it right in the query class, and in search modules like the Views integration. This makes sense insofar that sorting on multi-valued fields a) makes no real sense conceptually, at least in most cases, and b) is not supported by most backends (probably because of a)). Also, fulltext fields consist of tokens, so can also be seen as multi-valued – though sorting on things like node titles does make a lot of sense.
So, for the D8 version we should probably re-evaluate this regulation to see how much sense it makes. So, which of the following variants would you prefer for the D8 version:
- Allow sorting on fulltext fields, but not on multi-valued fields. Let the service classes figure out a way to support it.
- Allow sorting on all fields, even multi-valued. Again, the service classes have to figure out, how.
- Have no rule against it in the framework in general, but allow service classes to fail on or ignore sorts on particular fields. (Might be bad UX, if a search suddenly fails because you have set a wrong sort.)
- Make it optional via a feature (or features) that let service classes advertise what sorting they support. Alternatively, we could introduce a dedicated service class method,
canSortOn($field)
. In both cases, it would add additional complexity to the Views integration, and might be more confusing to users (i.e., site builders) than the current approach. - Just leave everything as it is.
For both Solr and the database, having to support sorting for fulltext and/or multi-valued fields would probably mean storing concatenated/condensed/single-valued versions of all such fields internally, thus increasing disk space usage (though, for Solr at least, the field at least wouldn't need to be stored). But it would definitely be possible, I guess.
And, in general, as how critical would you see this? Has the current regulation ever restricted functionality for you, or otherwise been a drawback for your project?
Comments
Comment #1
drunken monkeyAh, screw it, let's just sort on everything! Andrei is already implementing this for the DB backend, for Solr it should be even less complicated. And if it just isn't possible in some backend, it can still always throw an exception, or ignore the sort.
Committed this in the sandbox now.
Comment #5
drunken monkey