- 09 Aug, 2016 1 commit
-
-
tiagonbotelho authored
-
- 08 Aug, 2016 1 commit
-
-
Yorick Peterse authored
This concern provides an optimized/simplified version of the "cache_key" method. This method is about 9 times faster than the default "cache_key" method. The produced cache keys _are_ different from the previous ones but this is worth the performance improvement. To showcase this I set up a benchmark (using benchmark-ips) that compares FasterCacheKeys#cache_key with the regular cache_key. The output of this benchmark was: Calculating ------------------------------------- cache_key 4.825k i/100ms cache_key_fast 21.723k i/100ms ------------------------------------------------- cache_key 59.422k (± 7.2%) i/s - 299.150k cache_key_fast 543.243k (± 9.2%) i/s - 2.694M Comparison: cache_key_fast: 543243.4 i/s cache_key: 59422.0 i/s - 9.14x slower To see the impact on real code I applied these changes and benchmarked Issue#referenced_merge_requests. For an issue referencing 10 merge requests these changes shaved off between 40 and 60 milliseconds.
-
- 29 Jul, 2016 1 commit
-
-
Yorick Peterse authored
The method Ability.issues_readable_by_user takes a list of users and an optional user and returns an Array of issues readable by said user. This method in turn is used by Banzai::ReferenceParser::IssueParser#nodes_visible_to_user so this method no longer needs to get all the available abilities just to check if a user has the "read_issue" ability. To test this I benchmarked an issue with 222 comments on my development environment. Using these changes the time spent in nodes_visible_to_user was reduced from around 120 ms to around 40 ms.
-
- 12 Jul, 2016 1 commit
-
-
Robert Speicher authored
-
- 01 Jul, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Rémy Coutable authored
And create new Project#requesters, Group#requesters scopes. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 30 Jun, 2016 1 commit
-
-
Sean McGivern authored
-
- 23 Jun, 2016 1 commit
-
-
Sean McGivern authored
Postgres and MySQL don't guarantee that pagination with `LIMIT` and `OFFSET` will work if the ordering isn't unique. From the Postgres docs: > When using `LIMIT`, it is important to use an `ORDER BY` clause that > constrains the result rows into a unique order. Otherwise you will get > an unpredictable subset of the query's rows Before: [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten [2] pry(main)> issues.count => 81 [3] pry(main)> issues.uniq.count => 42 After: [1] pry(main)> issues = 1.upto(Issue.count).map { |i| Issue.sort('priority').page(i).per(1).map(&:id) }.flatten [2] pry(main)> issues.count => 81 [3] pry(main)> issues.uniq.count => 81
-
- 21 Jun, 2016 1 commit
-
-
Paco Guzman authored
-
- 16 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 13e37a3e.
-
James Lopez authored
-
- 14 Jun, 2016 2 commits
-
-
Rémy Coutable authored
+ Move 'Edit Project/Group' out of membership-related partial + Show the access request buttons only to logged-in users + Put the request access buttons out of in a more visible button + Improve the copy in the #remove_member_message helper Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 13 Jun, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 08 Jun, 2016 1 commit
-
-
Alejandro Rodríguez authored
This was not a clear cut n+1 query, given that if you're directly subscribed to all issues that the API is returning you never really need to check for the notes. However, if you're subscribed to _all_ of them, then for each issuable you need to go once to `notes`, and once to `users` (for the authors). By preemtively loading notes and authors, at worst you have 1 extra query, and at best you saved 2n extra queries. We also took advantage of this preloading of notes when counting user notes.
-
- 06 Jun, 2016 1 commit
-
-
Grzegorz Bizon authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 02 Jun, 2016 1 commit
-
-
Paco Guzman authored
This will be useful when you want to ask for the number of items and later iterate over them, without needing to ask if the association is load or not. So you avoid extra database queries
-
- 01 Jun, 2016 1 commit
-
-
Yorick Peterse authored
There are several changes to this module: 1. The use of an explicit stack in Participable#participants 2. Proc behaviour has been changed 3. Batch permissions checking == Explicit Stack Participable#participants no longer uses recursion to process "self" and all child objects, instead it uses an Array and processes objects in breadth-first order. This allows us to for example create a single Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using a ReferenceExtractor removes the need for running potentially many SQL queries every time a Proc is called on a new object. == Proc Behaviour Changed Previously a Proc in Participable was expected to return an Array of User instances. This has been changed and instead it's now expected that a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return value of the Proc is ignored. == Permissions Checking The method Participable#participants uses Ability.users_that_can_read_project to check if the returned users have access to the project of "self" _without_ running multiple SQL queries for every user.
-
- 31 May, 2016 1 commit
-
-
Felipe Artur authored
-
- 29 May, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-
- 24 May, 2016 5 commits
-
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Felipe Artur authored
-
Robert Speicher authored
Also removes the note from the development/testing.md guide
-
- 23 May, 2016 1 commit
-
-
Robert Speicher authored
-
- 12 May, 2016 2 commits
-
-
Ahmad Sherif authored
Closes #15638
-
Zeger-Jan van de Weg authored
-
- 11 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 10 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 06 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 27 Apr, 2016 1 commit
-
-
Grzegorz Bizon authored
This status will be returned only when there are no failed jobs that are not allowed to fail.
-
- 21 Apr, 2016 2 commits
-
-
James Lopez authored
-
James Lopez authored
-
- 20 Apr, 2016 3 commits
-
-
James Lopez authored
-
James Lopez authored
-
James Lopez authored
-