Last modified: 2011-01-20 18:56:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T26650, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 24650 - Fix API to work with categorylinks changes
Fix API to work with categorylinks changes
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.17.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks: 22744 26611
  Show dependency treegraph
 
Reported: 2010-08-03 21:18 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2011-01-20 18:56 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-08-03 21:18:36 UTC
Important points:

1) The index is now on (cl_to, cl_type, cl_sortkey, cl_from) instead of (cl_to, cl_sortkey, cl_from), where cl_type is enum('page', 'subcat', 'file').  WHERE cl_to='Foo' ORDER BY cl_sortkey is thus now a filesort.

2) cl_sortkey is now not human-readable, in principle.  Currently it sort of is, but it can have a null in it.  In the future, it will be totally binary, probably.
Comment 1 Sam Reed (reedy) 2010-08-26 23:10:20 UTC
ApiQueryCategoryMembers.php:

		$this->addWhereFld( 'cl_to', $categoryTitle->getDBkey() );
<snip>
		} else {
			$this->addWhereRange( 'cl_sortkey', ( $params['dir'] == 'asc' ? 'newer' : 'older' ), $params['startsortkey'], $params['endsortkey'] );
			$this->addWhereRange( 'cl_from', ( $params['dir'] == 'asc' ? 'newer' : 'older' ), null, null );
		}

So we're missing the index as we're not sorting on cl_type


We're using cl_sortkey as a continue. That probably needs changing.


ApiQueryCategories:

Output of sortkey is probably pointless now...?
Comment 2 Roan Kattouw 2010-09-10 21:07:52 UTC
(In reply to comment #1)
> So we're missing the index as we're not sorting on cl_type
> 
Besides sorting we should also actually be doing stuff with cl_type (outputting, filtering).

> We're using cl_sortkey as a continue. That probably needs changing.
> 
Yes, needs to be some compound key that forms a unique index.

> ApiQueryCategories:
> 
> Output of sortkey is probably pointless now...?
Let's keep it around for back compat. It's also not totally useless (useful for e.g. debugging collations and the like).
Comment 3 Bawolff (Brian Wolff) 2011-01-07 15:00:06 UTC
>> Output of sortkey is probably pointless now...?
>Let's keep it around for back compat. It's also not totally useless (useful for
>e.g. debugging collations and the like).

How about anywhere a sortkey is displayed in the api, we now have two fields, sortkey would be the human readable sortkey based cl_sortkey_prefix (on the assumption that most people using the api for sortkeys currently use it to display to user, not to sort things), and then another field, rawsortkey that has the binary sortkey in it.

Does that sound like the right course of action?
Comment 4 Sam Reed (reedy) 2011-01-14 21:34:24 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > So we're missing the index as we're not sorting on cl_type
> > 
> Besides sorting we should also actually be doing stuff with cl_type
> (outputting, filtering).

r80324 allows cl_type to be shown and allows filtering on cl_type

> 
> > We're using cl_sortkey as a continue. That probably needs changing.
> > 
> Yes, needs to be some compound key that forms a unique index.

That's the next job... See what I can come up with.

> 
> > ApiQueryCategories:
> > 
> > Output of sortkey is probably pointless now...?
> Let's keep it around for back compat. It's also not totally useless (useful for
> e.g. debugging collations and the like).

(In reply to comment #3)
> >> Output of sortkey is probably pointless now...?
> >Let's keep it around for back compat. It's also not totally useless (useful for
> >e.g. debugging collations and the like).
> 
> How about anywhere a sortkey is displayed in the api, we now have two fields,
> sortkey would be the human readable sortkey based cl_sortkey_prefix (on the
> assumption that most people using the api for sortkeys currently use it to
> display to user, not to sort things), and then another field, rawsortkey that
> has the binary sortkey in it.
> 
> Does that sound like the right course of action?

That seems sane. Hopefully people aren't doing anything, but we have no idea.

Keeping the names more like the cols is probably a better idea

Roan, what do you think about what Bawolff suggested?
Comment 5 Sam Reed (reedy) 2011-01-15 00:14:06 UTC
Right, all done by r80362, RELEASE-NOTES in r80363

Going to log a related bug too...

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links