Sortable index fields in views

You're right, it seems we forgot to implement this. Patch attached, please test!

PS: It seems you (like many others – it's really easy to misinterpret) are confused by the "Issue tags" field. As the guidelines state, they aren't meant for free text tags related to the issue, but only for specific categorization purposes, usually by module maintainers.
So, if you aren't sure your current usage is correct, please just leave the field empty.

I haven't done any manual testing but it looks good. Do you think we need to add a test or would this lead to too much duplication of views tests?

I already did manual testing, but automatic tests are of course even better. Wasn't too hard, either.

I noticed you used ++$i again, and I'd do it the other way around but that doesn't matter. We've had that discussion before. Test looks good and it's green, great job!

Yeah, let's not get into that. ;)
Thanks for reviewing!
Committed.

Changing status.

The new tests fail on Solr. The difference is in the "value" for an empty field.
I'm not sure if this is

• a bug in the DB backend regarding the "value"
• a different behavior of Solr regarding the "value"
• a bug in the Solr backend
• a difference we must accept

At the moment Solr "ignores" content that has no category assigned in the tests and always puts '[EMPTY]' on the bottom while the other values are sorted correctly ascending or descending.

I remember a similar "feature request" for apachesolr 7.x. I guess from Solr's perspective it is a feature.

Should we open new issues to deal with that difference? Should we at least isolate the new test that it could be overwritten in the Solr module?
Any ideas?

Yes, the current tests hard-code the assumption that NULL will count as the "lowest" possible value when sorting. This is not really defined anywhere in the Search API and just an assumption. (One that we're even lucky is true for all three DBMSs we test with, I guess. I'm not sure this is defined in the SQL standards – and even if it is, we know that doesn't mean all that much.)

Anyways, for fixing this in Solr, I think several options are viable:

1. Isolate those tests in a method that can easily be overridden in Solr.
2. For these calls, also filter for "category is not empty", so we don't have that problem (but less test coverage – e.g., this could mean we overlook specific problems/errors that only occur when sorting NULL values (though I guess we already test for those in the backend kernel tests)).
3. In Solr, set the "sort missing values first" option to keep this consistent with the DB backend. (Might still be a problem for other backends, though.)

Maybe we should open a new issue for this in any case, though. Feel free to ping me on IRC for further discussion.

After a discussion in IRC we modified the sorting behavior of our Solr backend to be compatible to the DB backend. BTW this behavior is Lucene's default behavior as well :-)