Last modified: 2011-03-13 18:05:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10297 - Patch that includes previous revision ID in prop=revisions
Patch that includes previous revision ID in prop=revisions
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.11.x
All All
: Lowest enhancement (vote)
: ---
Assigned To: Roan Kattouw
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-17 20:24 UTC by Roan Kattouw
Modified: 2011-03-13 18:05 UTC (History)
3 users (show)

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


Attachments
Includes previous revision ID in prop=revisions (875 bytes, patch)
2007-06-17 20:24 UTC, Roan Kattouw
Details
Revised patch (1.83 KB, patch)
2007-06-25 04:56 UTC, Yuri Astrakhan
Details

Description Roan Kattouw 2007-06-17 20:24:55 UTC
Created attachment 3797 [details]
Includes previous revision ID in prop=revisions

This is useful for implementing diffs in action=feedwatchlist (see also bug 10268) and for building diff links in general.
Comment 1 Roan Kattouw 2007-06-18 18:34:29 UTC
Could the attached patch be reviewed and applied to the trunk?
Comment 2 Yuri Astrakhan 2007-06-25 04:56:00 UTC
Created attachment 3821 [details]
Revised patch

I modified the patch a bit (attached), but it wouldn't work -- rc table may not contain relevant information (for example when the edit is old, imports, etc). It seems rev table is the only one with the needed info.
Comment 3 Roan Kattouw 2007-06-29 20:31:15 UTC
(In reply to comment #2)
> It seems rev table is the only one with the needed info.
The rev_parent_id was added in 1.10; getting lastids for pre-1.10 revisions wouldn't work either. It's better than using RC, though. I'll rework the patch.

Comment 4 Rob Church 2007-06-30 03:39:50 UTC
Note that revision.rev_parent_id does not contain the "previous revision" identifier, but rather, the revision from which the current can be considered to be derived. This might be further reinforced in the future to assist with "blame map" generation and additional anti-vandalism and analysis goodies.

Incorrectly relying upon a column is probably a bad idea if the data semantics are not what you expect later.
Comment 5 Roan Kattouw 2007-06-30 07:44:49 UTC
(In reply to comment #4)
> Note that revision.rev_parent_id does not contain the "previous revision"
> identifier, but rather, the revision from which the current can be considered
> to be derived.
That only leaves recentchanges.rc_last_oldid, which is only conserved for a week (sadly).

But then, how do they do this: http://en.wikipedia.org/w/index.php?title=Dog&diff=prev&oldid=178421 This edit is five years old, yet the previous and next revision are in the DB somehow. I think they do that based on timestamps in the revision table, I'll rewrite my patch to use that.
Comment 6 Roan Kattouw 2007-06-30 09:23:46 UTC
Fixed in r23584 (using timestamps in the revision table)
Comment 7 Yuri Astrakhan 2007-07-01 06:49:22 UTC
Reverted in 23596 because of the following:

* lastid is confusing. Need a better name.

* rvprop should behave in an expected manner. If the user asks for
timestamp, she should receive timestamp. If the user asks for lastid,
the user should NOT get the timestamp.

* DB must not be queried for each revision; instead a single query needs to be made. (not sure yet of how to do this, but multiple queries is not a solution)
Comment 8 Roan Kattouw 2007-11-29 14:18:02 UTC
Closing as WONTFIX since there appears to be no way to implement this without strangling the database.

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


Navigation
Links