Issue #328: model: UserLog has redundant username entry
| Reported by: | Thomas De Schampheleire |
| State: | closed |
| Created on: | 2018-09-11 09:02 |
| Updated on: | 2020-06-18 20:12 |
Description
model class UserLog has next to a user_id also a username field. This value is redundant because the username could be retrieved based on the user id. This redundancy adds to database size, but also makes it harder to rename a user via the database. In my case, such a rename for one user was needed after an LDAP database change.
Proposal is to remove the entry and lookup the username when needed (e.g. used in journal filtering) from the User table based on the user id.
Attachments
Comments
Comment by Mads Kiilerich, on 2018-09-11 10:36
I think we also could argue the opposite way.
Generally, it is nice to have data normalized and consistent. But for logging, we might want to store exactly how things were, even if that adds redundancy and is inconsistent with how things are now.
A simple and clear case is what should happen with log entries for users that are deleted. Should they be removed with the user? Probably not. This user_id/username redundancy do that we keep log entries for deleted users and can have an idea who they relate to.
One simple solution is to never delete anything, but only mark it as deleted and hide it from default views. That could work for users (and repositories?), but would be hard to do for things like access control.
Anyway: for the user case you describe, I guess you just should keep the log entries unmodified.
Comment by Thomas De Schampheleire, on 2018-09-11 11:55
Yes, you could argue that way. But it also means that when filtering the log you need to be aware of such username changes.
I did indeed keep the logs untouched now.
In fact, I never use the admin journal. Just found that there does not seem to be a way to delete entries in bulk, like: only retain the last month, or something like that. With many users this grows quite a lot. Future improvement maybe...
Comment by Mads Kiilerich, on 2018-09-12 08:50
It seems very likely that filtering needs tweaking to work "as intended", both when searching for deleted users, and renamed users with new or old name.
With proper indexes and mainly being append-only, I guess the size of the logs usually not will be a problem. But for systems with very heavy use, it would probably be nice to have functionality for pruning. Or perhaps just instructions about what to clean up in the database - such big installations will probably have a DBA anyway ;-)