- 01 Jul, 2016 1 commit
-
-
James Lopez authored
-
- 29 Jun, 2016 1 commit
-
-
James Lopez authored
-
- 03 Jun, 2016 2 commits
-
-
James Lopez authored
This reverts commit 3e991230.
-
James Lopez authored
# Conflicts: # app/models/project.rb
-
- 19 May, 2016 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 16 May, 2016 2 commits
-
-
Sean McGivern authored
Postgres only needs to select a single column, so that can used as a sub-query where `Milestone.upcoming_ids_by_projects` is actually used in `IssuableFinder`. MySQL needs to select the `due_date` column because it's used in the `HAVING` clause, so it has to return an array of IDs.
-
Sean McGivern authored
Before: we took the next milestone due across all projects in the search and found issues whose milestone title matched that one. Problems: 1. The milestone could be closed. 2. Different projects have milestones with different schedules. 3. Different projects have milestones with different titles. 4. Different projects can have milestones with different schedules, but the _same_ title. That means we could show issues from a past milestone, or one that's far in the future. After: gather the ID of the next milestone on each project we're looking at, and find issues with those milestone IDs. Problems: 1. For a lot of projects, this can return a lot of IDs. 2. The SQL query has to be different between Postgres and MySQL, because MySQL is much more lenient with HAVING: as well as the columns appearing in GROUP BY or in aggregate clauses, MySQL allows them to appear in the SELECT list (un-aggregated).
-
- 09 May, 2016 2 commits
-
-
Jeroen van Baarsen authored
In 8278b763 the default behaviour of annotation has changes, which was causing a lot of noise in diffs. We decided in #17382 that it is better to get rid of the whole annotate gem, and instead let people look at schema.rb for the columns in a table. Fixes: #17382
-
Felipe Artur authored
-
- 06 May, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 05 May, 2016 1 commit
-
-
Felipe Artur authored
-
- 21 Apr, 2016 3 commits
-
-
Alejandro Rodríguez authored
The changes also account for %2.1. being matched as milestone_name = "2.1" without the word-separating dot.
-
Alejandro Rodríguez authored
Also, addint a suffix to the reference text when the milestone is in another project
-
Alejandro Rodríguez authored
Using the syntax proposed in #13829 [project_reference]%(milestone_id | milestone_name) to get a link to the referred milestone.
-
- 01 Apr, 2016 2 commits
-
-
Yorick Peterse authored
Rails' "url_helpers" method creates an anonymous Module (which a bunch of methods) on every call. By caching the output of this method in a dedicated method we can shave off about 10 seconds of loading time for an issue with around 200 comments.
-
Yorick Peterse authored
These methods are called quite often in loops so by memoizing their output we can reduce timings a bit.
-
- 23 Mar, 2016 1 commit
-
-
Douwe Maan authored
-
- 17 Mar, 2016 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 12 Mar, 2016 3 commits
-
-
tiagonbotelho authored
-
tiagonbotelho authored
-
tiagonbotelho authored
-
- 11 Mar, 2016 1 commit
-
-
Yorick Peterse authored
-
- 07 Mar, 2016 1 commit
-
-
Rubén Dávila authored
-
- 02 Mar, 2016 2 commits
-
-
Rubén Dávila authored
-
Rubén Dávila authored
-
- 22 Feb, 2016 1 commit
-
-
Rubén Dávila authored
-
- 08 Feb, 2016 1 commit
-
-
Zeger-Jan van de Weg authored
Fixes #3903
-
- 03 Feb, 2016 1 commit
-
-
Rubén Dávila authored
-
- 02 Feb, 2016 3 commits
-
-
Rubén Dávila authored
-
Rubén Dávila authored
-
Rubén Dávila authored
-
- 08 Jan, 2016 1 commit
-
-
Robert Speicher authored
-
- 07 Jan, 2016 2 commits
-
-
Robert Speicher authored
Closes #5908
-
Douwe Maan authored
-
- 05 Jan, 2016 1 commit
-
-
Douwe Maan authored
-
- 24 Dec, 2015 1 commit
-
-
Douwe Maan authored
-
- 03 Dec, 2015 1 commit
-
-
Douwe Maan authored
-
- 02 Dec, 2015 1 commit
-
-
Douwe Maan authored
-
- 26 Nov, 2015 1 commit
-
-
Jose Corcuera authored
-
- 19 Oct, 2015 1 commit
-
-
Yorick Peterse authored
This cuts down the time it takes to sort issues of a milestone by about 10x. In the previous setup the code would run a SQL query for every issue that had to be sorted. The new setup instead runs a single SQL query to update all the given issues at once. The attached benchmark used to run at around 60 iterations per second, using the new setup this hovers around 600 iterations per second. Timing wise a request to update a milestone with 40-something issues would take about 760 ms, in the new setup this only takes about 130 ms. Fixes #3066
-