| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We dropped MySQL support and a lot of mysql specific code has been
removed in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29608.
This comes in from the other direction and removes any `if postgresql?`
branches.
|
|
We can reduce a significant number of queries by preloading the
associations for events.
On GitLab.com, for a date that had 456 events, this brought the load
time down from 8.7 to 1.2 s.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58392
|
|
|
|
|
|
This commit adds the module `FromUnion`, which provides the class method
`from_union`. This simplifies the process of selecting data from the
result of a UNION, and reduces the likelihood of making mistakes. As a
result, instead of this:
union = Gitlab::SQL::Union.new([foo, bar])
Foo.from("(#{union.to_sql}) #{Foo.table_name}")
We can now write this instead:
Foo.from_union([foo, bar])
This commit also includes some changes to make this new setup work
properly. For example, a bug in Rails 4
(https://github.com/rails/rails/issues/24193) would break the use of
`from("sub-query-here").includes(:relation)` in certain cases. There was
also a CI query which appeared to repeat a lot of conditions from an
outer query on an inner query, which isn't necessary.
Finally, we include a RuboCop cop to ensure developers use this new
module, instead of using Gitlab::SQL::Union directly.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/51307
|
|
This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.
|
|
|
|
the current syntax doesn't work properly in Rails 5, the resulting query
looks like:
HAVING "events"."project_id" IN (0)
instead of:
HAVING "events"."project_id" IN (SELECT "projects"."id" FROM...
Also we should not use ActiveRecord internal methods. In this case we
can filter projects in WHERE clause instead of doing this in HAVING
clause. Usage of WHERE should be also more efficient because grouping
is then done on much smaller subset of records.
|
|
contributions calendar
|
|
|
|
|
|
|
|
|
|
|
|
ContributionsCalendar class
|
|
|
|
This doesn't appear to be actually called twice, but having it appear to work
but not would be a problem if it was.
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Respect project visibility settings in the contributions calendar
This MR fixes a number of bugs relating to access controls and date selection of events for the contributions calendar
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/23403
See merge request !2019
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
This aligns the boxes correctly with the day on the left side of the calendar
|
|
|
|
|
|
When using MySQL as database backend in GitLab, ``date`` in ``date(created_at), count(id) as total_amount``
won't return the ``date`` column (should be ``date(created_at)``), as a result, there's no contribution in the user
profile page.
Adding an ``as date`` can solve this problem.
|
|
|
|
|
|
|
|
* count opening of issues and merge requests
* dont trigger git repository - use events from database
* much-much faster since does not affected by repository size
|
