Last modified: 2013-06-28 14:13:00 UTC
Tracking recent changes is a useful way for bots to stay in sync with a MediaWiki installation. One of the things I'd like to be able to track is which revisions were reverted. The recently added sha1 column is essential for detecting reverts. The sha1 column is available when making the request for a revision (prop=revisions), but not available when requesting revisions in recent changes (list=recentchanges). It appears that part of the reason for this is that the sha1 column does not appear in the MySQL recentchanges table. I propose that the rev_sha1 column be duplicated to the recentchanges (rc_sha1?) table and exposed via the web api.
(In reply to comment #0) > Tracking recent changes is a useful way for bots to stay in sync with a > MediaWiki installation. One of the things I'd like to be able to track is > which revisions were reverted. The recently added sha1 column is essential > for > detecting reverts. The sha1 column is available when making the request for > a > revision (prop=revisions), but not available when requesting revisions in > recent changes (list=recentchanges). It appears that part of the reason for > this is that the sha1 column does not appear in the MySQL recentchanges > table. > > I propose that the rev_sha1 column be duplicated to the recentchanges > (rc_sha1?) table and exposed via the web api. Why? Just join against revision and get it from there...
Well, first of all, joins are not possible (or highly impractical if performed manually) through the API. Why include any info about revisions in the recent changes table if we can get them by simply joining to the revision table? I'd argue that it's because the denormalization of the recentchanges table is useful for tracking information related to recent activity. The SHA1 field is particularly useful for tracking recent activities since it would allow me to detect reverts in (nearly) real time via the API. See my original filing of the bug to include checksum generation: https://bugzilla.wikimedia.org/show_bug.cgi?id=21860
(In reply to comment #2) > Well, first of all, joins are not possible (or highly impractical if > performed > manually) through the API. What?
I'm confused. If join *are* possible through the API, would you please demonstrate how to do it or point me towards the relevant documentation?
Not client side, I was meaning server side!! If you request the rev sha1 prop, its retrieved You can do client side joins to some extent with generators!
Ahh I see. While you're right that the sha1 could be pulled in via a join with revision on the server side, given that most other fields in revision are copied in recentchanges, I'd suggest that copying one more and saving the cost of the join would maintain consistency and perform better. As far as generators go, it appears that they would not be useful for this type of "join".
Related URL: https://gerrit.wikimedia.org/r/70435 (Gerrit Change I5cab770c2dd740d586dd75d8795cbf4e3c1d05b7)
Change 70435 merged by jenkins-bot: API: Add prop=sha1 to list=recentchanges https://gerrit.wikimedia.org/r/70435
Change merged. This should be deployed to WMF wikis with 1.22wmf10, see https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap for the schedule.
