Commit graph

9 commits

Author SHA1 Message Date
Sean McGivern
28e6af88aa Fix N+1 for notification recipients on private projects
If we don't call #to_a, we're relying on the members already being loaded from
elsewhere. Otherwise we'll do a separate query for each user:

    [1] pry(main)> Project.first.team.members.include?(User.first)
      Project Load (0.7ms)  SELECT  "projects".* FROM "projects"  ORDER BY "projects"."id" ASC LIMIT 1
      ↳ (pry):3
      User Load (1.8ms)  SELECT  "users".* FROM "users"  ORDER BY "users"."id" ASC LIMIT 1
      ↳ (pry):3
      User Exists (0.6ms)  SELECT  1 AS one FROM "users" INNER JOIN "project_authorizations" ON "users"."id" = "project_authorizations"."user_id" WHERE "project_authorizations"."project_id" = $1 AND "users"."id" = $2 LIMIT 1  [["project_id", 1], ["id", 1]]
      ↳ (pry):3
    => true
    [2] pry(main)> Project.first.team.members.to_a.include?(User.first)
      Project Load (12.8ms)  SELECT  "projects".* FROM "projects"  ORDER BY "projects"."id" ASC LIMIT 1
      ↳ (pry):1
      User Load (9.6ms)  SELECT "users".* FROM "users" INNER JOIN "project_authorizations" ON "users"."id" = "project_authorizations"."user_id" WHERE "project_authorizations"."project_id" = $1  [["project_id", 1]]
      ↳ (pry):1
      User Load (0.6ms)  SELECT  "users".* FROM "users"  ORDER BY "users"."id" ASC LIMIT 1
      ↳ (pry):1
    => true
2018-10-04 14:28:15 +01:00
Sean McGivern
819ecd5fb0 Fix N+1 for notification recipients in subscribers 2018-10-04 14:27:36 +01:00
Sean McGivern
37a6be36e2 Remove Gitaly N+1 ignore from NotificationRecipientService spec
This was because we were creating projects unnecessarily. These should be set as
the `source` for the notification setting, not the `project`!
2018-07-04 16:12:37 +01:00
Sean McGivern
f413c4dd26 Fix NotificationRecipientService spec for EE
EE checks a license, which needs RequestStore enabled to avoid N+1
queries. However, enabling RequestStore causes Gitaly to complain about N+1
invocations, which we really don't care about here.
2018-06-08 11:45:36 +01:00
Sean McGivern
0206476ae2 Fix some N+1s when calculating notification recipients
First N+1: we may have loaded a user's notification settings already, but not
have loaded their sources. Because we're iterating through, we'd potentially
load sources that are completely unrelated, just because they belong to this
user.

Second N+1: we do a separate query for each user who could be subscribed to or
unsubcribed from the target. It's actually more efficient in this case to get
all subscriptions at once, as we will need to check most of them.

We can fix both by the slightly unpleasant means of checking IDs manually,
rather than object equality.
2018-06-07 12:37:57 +01:00
http://jneen.net/
6aa44382ac rm a now-useless spec 2017-08-03 09:07:18 -07:00
Robert Speicher
72a7b30c9f Change all :empty_project to :project 2017-08-02 17:47:31 -04:00
Rémy Coutable
ddccd24c13 Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true
Signed-off-by: Rémy Coutable <remy@rymai.me>
2017-07-27 14:31:53 +02:00
Sean McGivern
60bd2ae372 Ensure NotificationRecipientService doesn't modify participants
Even though it does modify the participants of the notification target in some
cases, this should have been safe, as different workers are responsible for
creating the notifications for each target. However, this is at best confusing,
and we should ensure we don't do that.
2017-06-28 12:14:44 +01:00