Quote:
Originally Posted by kovidgoyal
@chaley: One way to do this is to add another operator to the search language that causes the search expression to be run on the sort version. Either another prefix character, or a second char after ~
|
Hmmm... That would require recomputing the sort string for every compare. I might be able to cache the value, thus changing it to once every search, but that might not help. Get_categories could provide the values, but this would slow every call down for a rare benefit.
Recomputing the string has some benefits, principally that the pattern would be applied to the same string computed in get_categories. However, the recomputation would likely be slower than applying the complex regexp.
Another alternate is to generate an =match for each series in a group, separated by 'or'. I think this would be very slow, but it would work as long as we don't run into length limitations.
We could also add "series_sort" to the db and field_metadata. This would speed up get_categories at the cost of loading the value when "meta" is evaluated. We would need to add an update trigger to write the value in the DB whenever the record is updated. This solution would also permit exposing series_sort in edit metadata, but that might create more problems than it is worth.
My guess is that the complex regexp is the easiest to build solution with the best performance.
Next would be a new column in the books table, set by a db upgrade and maintained by a trigger. This is easy for the tag browser, but would require all the kerfuffle to update the database and change field_metadata. It might also require changing OPF, but at first reflection I think not. If the field is not exposed, then there is no reason to pass it around.
Thoughts?