zerocrates
commented
2 years ago We could join on the linked resource id and get at that resource's title to sort by easily enough, but if the sorting is going to "just work" we'd need to have something like a null-coalesce which is going to be a problem for efficiency... probably the indexes wouldn't get used for sorting with a query like that, which could get pretty bad performance-wise. It also means incurring an extra join for all the literal-based sorts, which probably isn't ideal either.
An opt-in sort type (or another GET param that alters the sort query) that just always looks to join to a linked resource and sort on title would avoid indexing issues, but of course you'd have to choose to use that, and when you did use it you'd only sort on the linked titles and not on any "plain" values that might exist for that property in your result set.
We've talked before about a module making a sort table just for efficient sorting of expensive values (it would "index" the sort by saving the value to sort by and the resource ID in a table), and that kind of thing would work here also.
See https://github.com/omeka-s-modules/FacetedBrowse/issues/22 (Issue 1)
When sorting by a column of Omeka resources, the expectation is that it's sorted by resource title. However, when sorting by property term (e.g.
sort_by=dcterms:relation) we order byOmeka\Entity\Value.value, which is empty for values with the "resource" data type, resulting in unexpected sorting.Accommodating this behavior will be tricky since we have no prior knowledge that the entire sorting column will contain resource values.