Skip to content

Use specialized services for faster updates

What does this MR do?

When we're only updating a single attribute of a merge request, it can be MUCH faster to use a specialized update service for that specific attribute (or relationship) than the "update the world" approach of MergeRequests::UpdateService#execute does by default.

This MR leverages the work done in !57523 (merged) that added a new, specialized service for handling Assignee changes, integrating it back into the main UpdateService through a framework for adding other specialized services in the future. This potentially gives us a way to improve performance, as the majority of changes to Merge Request records are only touching attempting to update a single attribute at a time. When we know that the request is intended only to update a single attribute, we can avoid having to do as many queries and state comparisons to determine what changed by letting the request itself tell us..

Anecdotally in manual testing of adding/removing a 2nd and 3rd assignee to an MR, this reduces the query count from ~90 (and ~120) to ~30-35.

Related to #20827 (closed)

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Kerri Miller

Merge request reports