If the field is likely to be moving towards a binary field, this field becomes less useful.
I'm not sure replacing it with doing it on the more human readable sortkey_prefix...
Do we just deprecate and remove the parameters in 1.17 then?
Or leave it while it's semi useful..?
Version: unspecified
Severity: minor
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T28439 Deploy updated WMF branch to production (February 2011) | |||
| Resolved | None | T28676 Milestone: MediaWiki 1.17 release tarball (tracking) | |||
| Resolved | None | T28611 Bugs that should be fixed for 1.17 WMF deployment (tracking) | |||
| Declined | • Catrope | T28736 Usefulness of using (start|end)sortkey in ApiQueryCategoryMembers |
(In reply to comment #0)
If the field is likely to be moving towards a binary field, this field becomes
less useful.I'm not sure replacing it with doing it on the more human readable
sortkey_prefix...Do we just deprecate and remove the parameters in 1.17 then?
Or leave it while it's semi useful..?
I think it's probably useful to expose both. It's not a big deal to include unused information (as long as there's a prop to suppress it, and there is in this case), and it may be useful for debugging collation issues.
Or wait, do you mean the *paging* on sortkeys? That should only be left in if there's an index for it.
Yeah, I've left the sort key, and added the output of the sortkey prefix
I was meaning the paging, yeah. I suppose its still indexed, and still human readable, we might as allow the usage of starting sort key to filter on.
Just watching out for the sort key becoming more binary, at which point the human readable ones are useless, and hence the functionality is useless.
It is still in the main index, sooo....
WONTFIX for the moment?
(In reply to comment #3)
WONTFIX for the moment?
Yes. cl_sortkey_prefix is not indexed, and I think such an index is unlikely to be added.