Order projects by 'last_activity_at' in project lists
What does this MR do and why?
On project list pages, we sort project by 'Project Last Updated'. So users can see that projects are updated. Behind the scenes, we use updated_at
attribute. But that attribute is also used for invisible project updates that have no impact for users. So it could happen that a project that was not updated for months suddenly looks like it is updated.
This MR will change the ordering to last_activity_at
.
Related to #432410 (closed)
Reverted: updated_at
updated when last_activity_at
or last_repository_updated_at
is updated: !78572 (merged)
Reverted: Order by updated_at
!82488 (merged)
Use last_activity_at for project list ordering
The last_updated_at
column is updated:
- When an
Event
related to the project is recorded. This includes creation/updating Merge Requests, Issues, Milestones. - When code in the git repository is updated
This is aligned with Project Activity
The last_activity_at
column is indexed. No impact on performance is expected.
Use last_activity_at for the tooltip
Currently, we use the most recent of updated_at
, last_activity_at
and last_repository_updated_at
. Since we order now on last_activity_at
, we also should use that date/time value for the tooltip
Define project attributes that indicate 'activity'.
With this MR, updates to projects
records will no longer be regarded as "activity": changes to the Project instance do no longer update the last_activity_at
timestamp. However, for some attributes, this makes sense. So if a Project description or name is updated, we still change the last_activity_at
timestamp.
Database changes
Impact is the change from ORDER BY updated_at
to ORDER BY last_activity_at
.
Original query https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/25866/commands/81544
New query https://console.postgres.ai/gitlab/gitlab-production-tunnel-pg12/sessions/25866/commands/81545
In both cases, PostgreSQL is using top-N heapsort
. Query performance is similar.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Before | After |
---|---|
How to set up and validate locally
Using GDK, we first setup the dates of the projects:
- For each project:
- set
updated_at
to a random time between now and 24h ago - set
last_activity_at
to a random date/time up to 2 years ago
- set
in Rails console:
Project.all.each{|p| p.update_columns(last_activity_at: Time.now - rand(365 * 86400)) }
Project.all.each{|p| p.touch(time: Time.now - rand(86400)) }
Login and go to http://localhost:3000/dashboard/projects
Using master: project list is ordered by updated_at
, which can be seen because everthing happened 'XXX hours ago'
Using this branch: project list is ordered by last_updated_at
, which can be seen because everything happend longer ago