Usermerge userright - prospects for unmerging? - Wikitech-l - lists.wikimedia.org

List overview All Threads
Download

Usermerge userright - prospects for unmerging?

URL extraction from database

Tech updates: code updates going...

David Gerard

25 Mar 2009 25 Mar '09

4:27 p.m.

The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans. - d.

Reply

Show replies by date

Brion Vibber

25 Mar 25 Mar

9:49 p.m.

David Gerard wrote:

The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans.

I assume this is about the UserMerge extension? (Note we're not currently using this at Wikimedia.) It would probably be tricky to implement, but not impossible. Basically would need to record which revisions, log entries, etc got reassigned (potentially many tens of thousands in a single merge event) and their original assignment. -- brion

- d. _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

David Gerard

11:35 p.m.

2009/3/25 Brion Vibber <brion(a)wikimedia.org>rg>:

David Gerard wrote:

> The "usermerge" procedure is presently irreversible. Are there plans > for a way to make it reversible in case of error? I'm assuming error > (and a great deal of tedious mucking about to go back) is inevitable, > since the action is taken by humans.

I assume this is about the UserMerge extension? (Note we're not currently using this at Wikimedia.)

Oh, good! I say "oh, good!" because such a merge without unmerge has just too much potential for messes, and it was being discussed on functionaries-en-l (the latest incarnation of the Cabal), and I thought from the discussion it was switched on.

It would probably be tricky to implement, but not impossible. Basically would need to record which revisions, log entries, etc got reassigned (potentially many tens of thousands in a single merge event) and their original assignment.

Yeah. Before such a thing is switched on for WMF wikis, we'd need a way to avert the obvious hilarity ensuing from an error. Perhaps not keeping the records forever, but certainly enough for a week or a month's leeway to revert pressing the wrong button. - d.

Reply

Thomas Dalton

26 Mar 26 Mar

12:02 a.m.

2009/3/25 Brion Vibber <brion(a)wikimedia.org>rg>:

David Gerard wrote:

The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans.

I assume this is about the UserMerge extension? (Note we're not currently using this at Wikimedia.) It would probably be tricky to implement, but not impossible. Basically would need to record which revisions, log entries, etc got reassigned (potentially many tens of thousands in a single merge event) and their original assignment.

An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.

Reply

David Gerard

12:15 a.m.

2009/3/25 Thomas Dalton <thomas.dalton(a)gmail.com>om>:

An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.

I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the "original UID" in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of. - d.

Reply

Thomas Dalton

12:48 a.m.

2009/3/25 David Gerard <dgerard(a)gmail.com>om>:

2009/3/25 Thomas Dalton <thomas.dalton(a)gmail.com>om>:

An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.

I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the "original UID" in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of.

True, you could completely unmerge and them just remerge the parts that should be merged. Rather cruel on the servers if the accounts have been prolific, but it would work. (I'm not sure why we would want to merge sockpuppeting vandals, though - just block them all individually.)

Reply

Platonides

3:03 a.m.

David Gerard wrote:

I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the "original UID" in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of. - d.

Not sure if you're meaning this or talking about that intangible "new column": Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users).

Reply

Aryeh Gregor

3:07 a.m.

On Wed, Mar 25, 2009 at 9:03 PM, Platonides <Platonides(a)gmail.com> wrote:

Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users).

Those columns are supposed to be *consistent*. Deliberately making them inconsistent would be a really bad idea. (Although Special:Import often already does . . .)

Reply

Thomas Dalton

3:44 a.m.

2009/3/26 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:

On Wed, Mar 25, 2009 at 9:03 PM, Platonides <Platonides(a)gmail.com> wrote:

Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users).

Those columns are supposed to be *consistent*. Deliberately making them inconsistent would be a really bad idea. (Although Special:Import often already does . . .)

I agree. If you were going to do that you would need to go through every line of code to find anywhere where someone had assumed they were consistent (which could be a lot of places - it's a safe assumption, so why not make it?) and thus written code that would now be broken.

Reply

Aryeh Gregor

12:52 a.m.

On Wed, Mar 25, 2009 at 6:02 PM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:

An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.

That's a *lot* of extra columns for such a marginal feature. More likely we'd do something like log a blob that has a serialized list of everything changed. (This would require actually figuring out everything that was changed, of course, which already complicates things and probably slows them down.) If we want to revert, we'd load up the blob and build the queries from it.

Reply

David Gerard

1:17 a.m.

2009/3/25 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:

On Wed, Mar 25, 2009 at 6:02 PM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote:

> An extra column in any table with a "user id" column for "original > user id" (which would be identical to user id for the vast majority of > rows) would be sufficient for most unmerges. There would still be a > problem if an account was involved in more than one merge, though.

That's a *lot* of extra columns for such a marginal feature. More likely we'd do something like log a blob that has a serialized list of everything changed. (This would require actually figuring out everything that was changed, of course, which already complicates things and probably slows them down.) If we want to revert, we'd load up the blob and build the queries from it.

That sounds feasible, and allow blobs to expire after a certain length of time unreverted if the space gets onerous. - d.

Reply

Aryeh Gregor

2:29 a.m.

On Wed, Mar 25, 2009 at 7:17 PM, David Gerard <dgerard(a)gmail.com> wrote:

2009/3/25 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:

That's a *lot* of extra columns for such a marginal feature. More likely we'd do something like log a blob that has a serialized list of everything changed. (This would require actually figuring out everything that was changed, of course, which already complicates things and probably slows them down.) If we want to revert, we'd load up the blob and build the queries from it.

That sounds feasible, and allow blobs to expire after a certain length of time unreverted if the space gets onerous.

What, a few kilobytes per rename? At a handful of renames per day? Not likely to be a problem.

Reply

5504

days inactive

5505

days old

wikitech-l@lists.wikimedia.org

Manage subscription

11 comments

5 participants

tags (0)

participants (5)

Aryeh Gregor
Brion Vibber
David Gerard
Platonides
Thomas Dalton