Last modified: 2007-09-04 19:48:07 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 T13115, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11115 - Adding the sha1 to the imageinfo query
Adding the sha1 to the imageinfo query
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.11.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-29 22:17 UTC by Bryan Tong Minh
Modified: 2007-09-04 19:48 UTC (History)
1 user (show)

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


Attachments
Patch (806 bytes, patch)
2007-08-29 22:18 UTC, Bryan Tong Minh
Details

Description Bryan Tong Minh 2007-08-29 22:17:12 UTC
Now that the sha1 hashes of the images are available in the database, it would be handy to also expose them through the api. I have attached a trivial patch.
Comment 1 Bryan Tong Minh 2007-08-29 22:18:52 UTC
Created attachment 4059 [details]
Patch 

As above
Comment 2 Bryan Tong Minh 2007-09-01 14:25:34 UTC
Some characters are not allowed in XML and I think that we need to hexlify the hash before returning it. 
Comment 3 Rob Church 2007-09-01 14:33:21 UTC
A SHA-1 hash *is* a hexadecimal number, and is thus alphanumeric.

Even if it weren't, assuming the API isn't insane, it'll be passing all values through the standard XML functions (see includes/Xml.php), or else using something sensible to generate valid XML, so this wouldn't be an issue.
Comment 4 Roan Kattouw 2007-09-02 19:23:02 UTC
(In reply to comment #3)
> Even if it weren't, assuming the API isn't insane, it'll be passing all values
> through the standard XML functions (see includes/Xml.php), or else using
> something sensible to generate valid XML, so this wouldn't be an issue.

I haven't looked at the imageinfo code, but I dare say our XML (and other output formats, FTM) handling is sane. I'll test this patch tomorrow, and if it works, I'll commit it.
Comment 5 Roan Kattouw 2007-09-03 20:03:09 UTC
For some insane reason, the DB stores SHA1 hashes in base 36. I understand base 64 may not have been feasible due to uppercase/lowercase issues, but base 32 makes a lot more sense to me than 36. Also, storing it in hex (much less trouble) costs only 8 bytes per image (a negligible difference considering the images themselves range from 10 KB to 10 MB) and eliminates the wfBaseConvert() overhead. Would this be a sensible schema change?

Either way, it's fixed in r25456. Thanks to Bryan for the patch, which needed very little work.
Comment 6 Brion Vibber 2007-09-04 19:44:20 UTC
I used a base-36 version of the hash keys for *filenames* in the deletion archive repository because they're more compact, and thus less unfriendly for URLs.

Not sure if they're the best thing to use in the DB, but *eh*. Gotta pick something. :)
Comment 7 Roan Kattouw 2007-09-04 19:48:07 UTC
(In reply to comment #6)
> I used a base-36 version of the hash keys for *filenames* in the deletion
> archive repository because they're more compact, and thus less unfriendly for
> URLs.
Well like I said, the difference between base 36 and base 16 is only 8 bytes per image, and eliminates conversions. But then those conversions don't take up an earth-shattering amount of time either...

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


Navigation
Links