renaming users

Robert Jäschke reporter

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.

2013-11-07T08:50:14+00:00

Robert Jäschke 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.

2013-11-08T08:05:02+00:00

Robert Jäschke 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.