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