Skip to content

Project: update `updated_at` if other timestamps are changed

Jonas Wälter requested to merge siemens/gitlab:project/touch-updated_at into master

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.

🛠 with at Siemens

/cc @bufferoverflow

How to set up and validate locally

  1. Navigate to a project in the UI
  2. Change a project setting (e.g. description) or star/unstar the project updated_at is updated
  3. Create an issue or milestone last_activity_at and thus updated_at are updated
  4. Push to the repository last_repository_updated_at and thus updated_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.

Edited by Jonas Wälter

Merge request reports