- 12 Nov, 2016 1 commit
-
-
Oswaldo Ferreira authored
- Also remove unnecessary param
-
- 07 Oct, 2016 1 commit
-
-
Nick Thomas authored
-
- 19 Sep, 2016 1 commit
-
-
Z.J. van de Weg authored
-
- 28 Aug, 2016 1 commit
-
-
barthc authored
prevent authored awardable thumbs votes prevent authored awardable thumbs votes
-
- 20 Aug, 2016 1 commit
-
-
Stan Hu authored
`discussion_id` may not be present when the SELECT call for notes does not include this attribute. Don't attempt to set the discussion ID unless the model contains the attribute. Closes #21119, #21128
-
- 19 Aug, 2016 1 commit
-
-
Douwe Maan authored
-
- 18 Aug, 2016 1 commit
-
-
Douwe Maan authored
-
- 17 Aug, 2016 2 commits
-
-
Douwe Maan authored
-
Douwe Maan 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
-
-
Douwe Maan authored
-
- 26 Jul, 2016 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 23 Jul, 2016 1 commit
-
-
Douwe Maan authored
Fix bug where replies to commit notes displayed in the MR discussion tab wouldn't show up on the commit page
-
- 20 Jul, 2016 1 commit
-
-
Douwe Maan authored
-
- 14 Jul, 2016 1 commit
-
-
dixpac authored
* There where path where +1 was stored as +1 not as thumbsup that was causing problems such as showing thumbsup icon 2 time. I fixed this to always normalize and store +1 as tumbsup
-
- 11 Jul, 2016 1 commit
-
-
Stan Hu authored
have been fully redacted and contain cross-project references. The previous implementation relied on Note#cross_reference_not_visible_for?, which essentially tries to render all the Markdown references in a system note and only displays the note if the user can see the referring project. But this duplicated the work that Banzai::NotesRenderer was doing already. Instead, for each note we render, we memoize the number of visible user references and use it later if it is available. Improves #19273
-
- 06 Jul, 2016 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
Extract parts of LegacyDiffNote into DiffOnNote concern and move part of responsibility to other classes
-
- 04 Jul, 2016 1 commit
-
-
Douwe Maan authored
-
- 01 Jul, 2016 1 commit
-
-
James Lopez authored
-
- 29 Jun, 2016 1 commit
-
-
James Lopez authored
-
- 24 Jun, 2016 1 commit
-
-
Yorick Peterse authored
This commit changes the way certain documents are rendered (currently only Notes) and how documents are redacted. Previously both rendering and redacting would run on a per document basis. The result of this was that for every document we'd have to run countless queries just to figure out if we could display a set of links or not. This commit changes things around so that redacting Markdown documents is no longer tied into the html-pipeline Gem. This in turn allows it to redact multiple documents in a single pass, thus reducing the number of queries needed. In turn rendering issue/merge request notes has been adjusted to take advantage of this new setup. Instead of rendering Markdown somewhere deep down in a view the Markdown is rendered and redacted in the controller (taking the current user and all that into account). This has been done in such a way that the "markdown()" helper method can still be used on its own. This particular commit also paves the way for caching rendered HTML on object level. Right now there's an accessor method Note#note_html which is used for setting/getting the rendered HTML. Once we cache HTML on row level we can simply change this field to be a column and call a "save" whenever needed and we're pretty much done.
-
- 23 Jun, 2016 2 commits
-
-
Paco Guzman authored
-
Z.J. van de Weg authored
This commit eager loads the award emoji on both the issues and the MRs. When loading an issue with 108 comments this reduces the query count by 327 queries. On a merge request with the same amount of comments this saves 148 queries. The large difference is not clear to me at this point and the total query count is still huge with 387 and 1034 respectively. The biggest problem however, remains the calculation of participants.
-
- 16 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 13e37a3e.
-
James Lopez authored
-
- 15 Jun, 2016 1 commit
-
-
Z.J. van de Weg authored
-
- 13 Jun, 2016 3 commits
-
-
Douglas Barbosa Alexandre authored
-
Douglas Barbosa Alexandre authored
-
James Lopez authored
-
- 06 Jun, 2016 1 commit
-
-
ZJ van de Weg authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 01 Jun, 2016 2 commits
-
-
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.
-
Z.J. van de Weg authored
-
- 31 May, 2016 1 commit
-
-
Valery Sizov authored
-
- 29 May, 2016 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
-