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