Jools Smyth schreef:

...

Isn't "the revision your edits are based on" the same revision as "the last revision"? You're really just saying the same thing twice, but using different wordings.

Well, I guess the point im trying to make, is that whilst you are doing something with some data, someone else could edit it, and in that case the timestamp isnt of the last revision but the revision from where you "grabbed the page". See I thought just before submitting some data, you had to re-check for the most recent timestamp to edit. Maybe my brain wasn't working but I think some areas of the documentation could be easier.

No, you don't have to. action=edit just compares your basetimestamp to the timestamp of the most recent revision, and if they're not exactly the same, you'll get an edit conflict most of the time (there are some exceptions to that rule that I can't recall right now, like new section creations; for more, see the comments and code in EditPage::attemptInternalSave()).

Roan Kattouw (Catrope)

Brad Jorsch schreef:

On Thu, Oct 23, 2008 at 06:36:24PM +0100, Jools Smyth wrote:

...

Get page contents and store the timestamp - make some changes to the page. when I edit pass my timestamp back to the API.

Is this correct? If so, maybe the documentation would be better to say "you also need the timestamp of the revision your edits are based on" ?

What you really need to pass is the timestamp of the last revision of the page ''at the time you got the edit token for the page'', which might theoretically be different from the timestamp of the revision your edits are "based on", depending on how you define "based on".

Actually, using a different timestamp than the last revision's timestamp will fail: the edit conflict check requires that the timestamp are *exactly the same*, so timestamps of earlier revisions *or* later revisions *will* *not* *work*. You really need to get that one timestamp. (I apologize for overusing the * in this paragraph.)

I usually query prop=info|revisions&intoken=edit&rvprop=timestamp|content to get all three (token, timestamp, and content) in one query; leave out "|content" if you don't need it, of course.

I guess that's the easiest way, but you may not need it if you're adding a new section or replacing the page altogether.

Roan Kattouw (Catrope)

So to clarify things.

I get the contents of a page along with timestamp and edit token. a delay someone else edits the page I submit an edit request with my timestamp and edit token and my new contents

in this case it will fail ?

Right. And you *want* it to fail, because otherwise you'll be reverting someone else's changes.

-Ran Ari-Gur (user "Ruakh" on e.g. en.wikt)

On Thu, Oct 23, 2008 at 5:04 PM, Jools Smyth buzz@exotica.org.uk wrote:

...

Actually, using a different timestamp than the last revision's timestamp will fail: the edit conflict check requires that the timestamp are *exactly the same*, so timestamps of earlier revisions *or* later revisions *will* *not* *work*. You really need to get that one timestamp. (I apologize for overusing the * in this paragraph.)

This is what I initially thought, but was told by someone it was not correct.

So to clarify things.

I get the contents of a page along with timestamp and edit token. a delay someone else edits the page I submit an edit request with my timestamp and edit token and my new contents

in this case it will fail ?

Or should it be like

I get the contents of a page along with timestamp and edit token a delay someone else edits the page get another timestamp of latest revision Submit a edit request with my new timestamp and edit token and my new contents

Best Regards

Jools

---

Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

Jools Smyth schreef:

...

Right. And you *want* it to fail, because otherwise you'll be reverting someone else's changes.

ok. I understand now. what sort of error would the api return ?

The 'editconflict' error, IIRC. There's a full list of errors the action=edit module can throw on its page in the API docs [1].

Roan Kattouw (Catrope)

[1] http://www.mediawiki.org/wiki/API (the page about action=edit is linked from the right navbox)

Russell Blau wrote:

"Roan Kattouw" roan.kattouw@home.nl said:

...

Actually, using a different timestamp than the last revision's timestamp will fail: the edit conflict check requires that the timestamp are *exactly the same*, so timestamps of earlier revisions *or* later revisions *will* *not* *work*. You really need to get that one timestamp. (I apologize for overusing the * in this paragraph.)

This confused me. How can there be a "later revision" than "the last revision's timestamp"? Either the revision is the last one, or it is not....

Russ

You could be trying to trick mediawiki by passing timestamps in the future, or timestamps to newer, now-deleted revisions.

Guess Who? schreef:

just as a matter of curiosity, why do you use timestamps here, rather than revision ids? it seems to me there would be less confusion that way: this is the revision id for the particular version of the page I am making changes to; if the page I try to edit has a different revision id, then clearly it's been changed.

I didn't write the edit conflict detection code, so I don't have a definitive answer, but I'll hazard a guess. All I really know about the conflict detection code is that it's old, probably so old that it predates the existence of the revision table. Before the revision table existed, revisions were spread over two tables, the cur table for current revisions and the old table for old revisions (this is also why index.php still has the oldid and curid parameters). This is really ancient history (the revision table was introduced in MW 1.5), so I'll have to do a little guesswork here because I've only been around since 1.10 or so. My guess is that when a revision was moved from the cur table to the old table (because a newer revision was added), its ID changed. This means the revid-based approach doesn't work because revisions have two, possibly different, IDs in their lifetime (a cur_id and later an old_id) and revision IDs aren't unique (there can be two revisions with a given ID, one in the cur table and one in the old table). That's probably the reason why whoever wrote that code decided to use timestamps (again, this is just a guess).

but at any rate, let me see if I can summarize it correctly:

1. get the latest revision of the page, along with its timestamp

2. make the changes you want to make

3. resubmit the changed page with the timestamp you got in (1).

   a) if it matches, that means the revision you were working on is still the latest revision, and the edit goes through

   b) if it doesn't match, some change was made to the page (or something funky happened with the timestamp) and the server sends back an edit conflict (or other) error.

That's basically how it works, except that MediaWiki will suppress edit conflicts (i.e. let an edit through even when the timestamps don't match) in some cases. I alluded to this in an earlier message, but for clarity I compiled a list of special cases below.

* If you're creating a new article, there is no previous revision you can conflict with and the whole timestamp matching thing isn't done ** ...except when the article was deleted after the timestamp in the starttime parameter and you didn't set the recreate parameter. In practice, this means the page was deleted after you obtained the timestamp * If you're appending a new section to an article with section=new, edit conflicts are irrelevant because you wanted to append something new to the bottom anyway ** ...except when the conflicting revision was made by you and had the same summary as your edit. In this case MW assumes you (or Squid) submitted the same edit twice and throws an edit conflict anyway * If the conflicting revision was made by you, MW assumes you know what you're doing and doesn't throw an edit conflict ** ...except when the edit you're submitting is a section edit, in which case it needs to be merged (see next item) * If MW manages to merge your edit into the conflicting revision(s), the conflict is resolved and everybody is happy ** In theory, merging should succeed whenever your edit and the conflicting revision(s) don't change the same lines, but I don't know how well that works in practice

Roan Kattouw (Catrope)