Commit graph

7 commits

Author SHA1 Message Date
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