Page MenuHomePhabricator

Usefulness of using (start|end)sortkey in ApiQueryCategoryMembers
Closed, DeclinedPublic

Description

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

Details

Reference
bz26736

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 11:23 PM
bzimport set Reference to bz26736.

(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.