Ira Abramov wrote:
I advise against that! It messes up the entries in
other tables where
"user #348 edited this page" points to a user that is no
longer there or
hasn't even subscribed yet. As you pointed in points 5 and 6.
I'm unclear on why you see this as such a problem. If I change user_id 450
to 250 *and* update every instance of user_id 450 in the database to 250
everything should remain consistent.
lucky all of them had the same rights I guess.
otherwise you
might have
ended with the rights of the old user given to a new one after the
renumbering...
Probably something I should have mentioned. Since I'm the only sysop on my
wiki, this wasn't an issue. Seems unlikely, if not impossible, that a user
created in between the bot creations would have special rights, but it's
something to be aware of.
that's the mess I meant.
Yes, but if all of the references are updated, it isn't a mess.
might as well have left the numbers and just deleted
the bots from the
list... so the users' table has gaps in it, who cares?
Obviously... I do :).
My concern was that at some point in the future those gaps were going to
come back and bite me on the bum. Gaps in databases have a bad habit of
causing hard-to-diagnose problems a couple of upgrades out.
last but not least, one of the dangers of changing a
user's UID
retroactively are persistant cookies.
Possible, and, believe it or not, something I did consider, but in the end
decided it seemed pretty unlikely. I presume, perhaps incorrectly, that out
of user_id, username, and password at least two have to match else I could
just manually change my cookie to show UID of 1 on any wiki and likely
hijack a sysop account. Even ignoring that, quite frankly 99.99% of my users
never do squat so they'd be pretty unlikely to notice all of the awesome
evil powers a changed UID could grant them anyway.
Myria