Project: update `updated_at` if other timestamps are changed
What does this MR do and why?
In the Project
model, there are the two timestamps last_activity_at
and last_repository_updated_at
. These are currently updated without the timestamp updated_at
being updated as well. So we have three timestamps, which all hold the last change timestamp of a part of the project. To get the timestamp of the actual last change, the maximum of the three timestamps must be calculated. If you want to sort a project list by the timestamp of the actual last change, you will encounter database performance problems.
We tried to solve this problem with different approaches:
- (A) Add an index using
GREATEST(updated_at, last_activity_at, last_repository_updated_at)
- see !75350 (closed) - (B) Add a separate column containing the actual greatest timestamp using a trigger - see !77497 (closed)
Unfortunately, with (A) the existing datetime inconsistencies lead to difficulties and (B) is not an ideal solution from a database point of view. So the question arose, why the updated_at
column is actually not automatically updated by changing last_activity_at
or last_repository_updated_at
and thus always contains the actual timestamp of the last change. And according to !77497 (comment 814805839), there's no reason against it.
So this MR ensures that when last_activity_at
or last_repository_updated_at
is changed, updated_at
is updated as well.
/cc @bufferoverflow
How to set up and validate locally
- Navigate to a project in the UI
- Change a project setting (e.g. description) or star/unstar the project
➡ updated_at
is updated - Create an issue or milestone
➡ last_activity_at
and thusupdated_at
are updated - Push to the repository
➡ last_repository_updated_at
and thusupdated_at
are updated
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.