renaming users
add support for renaming users, i.e., for changing their user names
Comments (7)
-
reporter -
reporter There are some more things which we must take care of:
1) We must ensure, that the user can not change/update things while we update the posts. 2) We must change the user's authentification cookie while he/she's logged in.
It's not clear now, how difficult 2) is. We could possibly combine both: In one transaction, insert the user's new account into the user table, change the user's cookie and disable his old account. Then, update all his data in the tables. Finally, remove (?) the old row from the user table.
Potential problems: while we update, the user could create new posts under his/her new user name that raise duplicate errors.
-
reporter We will adopt solution number 1) from message [2013-11-07 08:50], i.e., we will update the user's name and ensure proper locking by first inserting a new row in the user table and then deleting the old row.
-
- changed status to open
-
- marked as task
-
Please keep in mind that a user can represent a group
-
- removed responsible
- Log in to comment
Outcome of discussion in yesterday's telco are two opposing approaches for which we could not settle a decision:
1) We really update all the tables in the database with the new name and log the fact that the name was updated in a new table. This requires appropriate locking levels in the database, such that nobody can register an account with the new name in the meantime. Actually, this is only true for the user table: we could insert (!) the new user first and delete the old after we updated all other tables. This should require no long table-level locking.
2) We delete all data and re-insert it with the new name. This is really a heavy overhead for the database.