summaryrefslogtreecommitdiff
path: root/lib/api/helpers/notes_helpers.rb
diff options
context:
space:
mode:
authorStan Hu <stanhu@gmail.com>2019-08-22 00:19:44 -0700
committerStan Hu <stanhu@gmail.com>2019-08-22 22:28:47 -0700
commite24b9c2502613cc0df5b2a676236d1c36c02bca4 (patch)
tree8384f8dbb4fa2ca6ebebed3cfd774e81371a859f /lib/api/helpers/notes_helpers.rb
parentba67965ac5386164a38acda32ff4e547e61b0376 (diff)
downloadgitlab-ce-e24b9c2502613cc0df5b2a676236d1c36c02bca4.tar.gz
Eliminate Gitaly N+1 queries with notes APIsh-eliminate-gitaly-nplus-one-notes
Similar to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31834, we see that in https://gitlab.com/gitlab-org/gitlab-ce/issues/65957 there can be hundreds, even thousands, of Gitaly requests in the `/api/:version/projects/:id/merge_requests/:noteable_id/notes` endpoint. Previously, the API to retrieve notes generated hundreds of Gitaly calls to determine whether a system note should be shown to the user. It did this by: 1. Rendering the Markdown 2. Extracting cross-references from the Markdown 3. Issuing a Gitaly `FindCommit` RPC for every reference to validate that the commit exists. The last step is unnecessary because we don't need to display a commit if the user doesn't have access to the project in the first place. `RendersNotes#prepare_notes_for_rendering` is already used in `MergeRequestsController`, which is why we don't see N+1 Gitaly calls there. We use it here to optimize the note redaction process.
Diffstat (limited to 'lib/api/helpers/notes_helpers.rb')
-rw-r--r--lib/api/helpers/notes_helpers.rb2
1 files changed, 2 insertions, 0 deletions
diff --git a/lib/api/helpers/notes_helpers.rb b/lib/api/helpers/notes_helpers.rb
index 6bf9057fad7..b2bf6bf7417 100644
--- a/lib/api/helpers/notes_helpers.rb
+++ b/lib/api/helpers/notes_helpers.rb
@@ -3,6 +3,8 @@
module API
module Helpers
module NotesHelpers
+ include ::RendersNotes
+
def self.noteable_types
# This is a method instead of a constant, allowing EE to more easily
# extend it.