| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts the addition of the "goldiloader" Gem and all use of it.
While this Gem is very promising it's causing a variety of problems on
GitLab.com due to it eager-loading too much data in places where we
don't expect/can handle this. At least for the time being this means we
have to go back to manually fixing N+1 query problems, but at least
those should not cause a negative impact on availability.
|
|
Goldiloader is great, but has several issues with has_many :through relations:
* https://github.com/salsify/goldiloader/issues/12
* https://github.com/salsify/goldiloader/issues/14
* https://github.com/salsify/goldiloader/issues/18
Rather than try to figure out which applies in each case, we should just do the
drudge work of manually disabling autoloading for all relations of this type. We
can always use regular preloading for specific cases, but this way we avoid
generating invalid queries through Goldiloader's magic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Group milestones can only be referred to by name, not IID. They also do not
support cross-project references.
|
|
|
|
This is allowed for existing instances so we don't end up 76 offenses
right away, but for new code one should _only_ use this if they _have_
to remove non database data. Even then it's usually better to do this in
a service class as this gives you more control over how to remove the
data (e.g. in bulk).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removed `Milestone#is_empty?` because is not used anymore in the codebase
|
|
|
|
|
|
|
|
|
|
Also added relevant specs and refactored to_references in a bunch of places to be more consistent.
|
|
Memoize Milestoneish#issues_visible_to_user and counts to reduce lookups
Milstoneish SQL optimised with project, but still slow on GlobalMilestone
|
|
|
|
|
|
This commit adds a number of _html columns and, with the exception of Note,
starts updating them whenever the content of their partner fields changes.
Note has a collision with the note_html attr_accessor; that will be fixed later
A background worker for clearing these cache columns is also introduced - use
`rake cache:clear` to set it off. You can clear the database or Redis caches
separately by running `rake cache:clear:db` or `rake cache:clear:redis`,
respectively.
|
|
in db as unescaped.
Updating test value for milestone title
Adding API test for title with reserved HTML characters.
Updating changelog
Adding the MR number for fixing bug #22452.
removing duplicate line
Updating MR number.
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
eReGeBe/gitlab-ce-feature/milestone-md
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
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.
|
|
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).
|
|
Remove the annotate gem and delete old annotations
In 8278b763d96ef10c6494409b18b7eb541463af29 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
/cc @yorickpeterse
See merge request !4099
|
|
In 8278b763d96ef10c6494409b18b7eb541463af29 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
|
|
Sanitize milestones and labels titles
fixes #15394
See merge request !4046
|
|
|
|
|
|
|
|
`milestone_iid`s
The changes also account for %2.1. being matched as milestone_name = "2.1" without
the word-separating dot.
|
|
Also, addint a suffix to the reference text when the milestone is in another project
|
|
Using the syntax proposed in #13829 [project_reference]%(milestone_id | milestone_name)
to get a link to the referred milestone.
|
|
Added & use Gitlab::Routing for URL helpers
Extracted from !3389
See merge request !3486
|
