Age | Commit message (Collapse) | Author |
|
- Move code for creating a new column from old into a function so that
it can be reused.
- Also add comments above the methods.
|
|
|
|
- Also add helper to undo rename_column_concurrently.
|
|
- When renaming a column concurrently, drop any existing trigger before
attempting to create a new one.
When running migration specs multiple times (as it happens during
local development), the down method of previous migrations are called.
If any of the called methods contains a call to
rename_column_concurrently, a trigger will be created and not removed.
So, the next time a migration spec is run, if the same down method is
executed again, it will cause an error when attempting to create the
trigger (since it already exists). Dropping the trigger if it already
exists will prevent this problem.
|
|
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.
|
|
Revert "Workaround for Rails 5, where LIMIT..."
See merge request gitlab-org/gitlab-ce!30780
|
|
https://gitlab.com/gitlab-org/gitlab-ce/issues/58792
|
|
None of this code can be reached any more, so it can all be removed
|
|
This improves the `add_timestamps_with_timezone` helper by allowing the
column names to be configured. This has the advantage that unnecessary
columns can be avoided, saving space.
A helper for removing the columns is also provided, to be used in the
`down` method of migrations.
|
|
This reverts commit 6823e7defb45dfd86d5258b40d6f82482d1ef451.
Originally implemented in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21839, but an
error was reported in
https://gitlab.com/gitlab-org/gitlab-ce/issues/51729 resulting in a
workaround introduced in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21879.
Now Rails 5.2 is used, this workaround no longer seems needed, so this
reverts it.
|
|
Updates changed method names and fixes spec failures
|
|
Suggests to use a JSON structured log instead
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102
|
|
|
|
|
|
So funny story, true story. I tried to run the test locally, but
didn't make it past setting up Gitaly.
Here's what I tried:
First attempt:
`git clone gitlab-ce`
`cd gitlab-ce && bundle install`
`be rspec`
This didn't work because I was missing the config/database.yml, I
didn't see a `script/bootstrap` so I looked in the readme which
redirected me to a webpage which redirected me to the
gitlab-development-kit.
Second attempt:
`gem install gitlab-development-kit`
cd gitlab-development-kit
gdk init
gdk isntall
This broke somwhere along the way because it couldn't install Gitaly
because my go version was too low. But it did clone the gitlab repo
again and this time it did have a config/database.yml.
So I tried to cd into it and `be rspec
spec/lib/gitlab/database/migration_helpers_spec.rb` which complained
about the database not being configured so I:
- Changed the socket to localhost (in the config/database.yml)
- `createdb <dev_db>` `createdb test_db`
- `be rake db:test:prepare`
Great success, it was doing things! But then failed when it came at
the Gitaly step.
Since I only want to change these three lines, at the point I gave up
and entrusted the pipeline to do its thing.
What I would have liked:
- A 'It's a Rails system, I know this' readme/docs (It's in there
somewhere just couldn't find it)
- A way to run tests without having to use Gitaly
- Not having too install all the things for a small fix (I get why'd
you want this, but to me it's overkill)
|
|
The rather cryptic:
"fk_#{Digest::SHA256.hexdigest("#{table}_#{column}_fk").first(10)}"
Was too much for emacs too handle*, since it was coming from the Rails
codebase I took their way of doing the same thing and applied it here.
I think it's easier to read and it also makes emacs render the
migration helpers pretty again.
* not true, emacs can handle anything, leave emacs alone!
|
|
This is necessary for backporting the EE schema to ensure backported
foreign keys use the same key names.
|
|
|
|
This was incorrectly set by a bug in:
https://gitlab.com/gitlab-org/gitlab-ce/issues/54924
Also adds a `batch_size` option to `update_column_in_batches`
|
|
|
|
This produces stable approximate counts among invocations unless the
table changed.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58791.
|
|
1. Ignore tables that use STI in reltuples count strategy.
Models that use Rails' single-type inheritance, such as `Group` and
`CiService`, need an additional WHERE clause to count the total
properly, which isn't supported by the reltuples strategy. For now,
we just omit these from the statistics sampling and rely on the other
strategies to get this data.
2. Fix tablesample count strategy not counting groups properly.
Models such as `Group` needs a WHERE clause to distinguish it from
namespaces. We now add in the WHERE clause if STI is in use.
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/7435
|
|
This style change enforces `return if ...` instead of
`return nil if ...` to save maintainers a few minor review points
|
|
|
|
|
|
|
|
The numbers in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22650#note_117645395
are quite promising with that target.
|
|
This improves readability quite a bit.
|
|
|
|
|
|
|
|
|
|
A tablesample count executes in two phases:
* Estimate table sizes based on reltuples.
* Based on the estimate:
* If the table is considered 'small', execute an exact relation count.
* Otherwise, count on a sample of the table using TABLESAMPLE.
The size of the sample is chosen in a way that we always roughly scan
the same amount of rows (see TABLESAMPLE_ROW_TARGET).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Enables frozens string for the following:
* lib/gitlab/conflict/**/*.rb
* lib/gitlab/cross_project_access/**/*.rb
* lib/gitlab/cycle_analytics/**/*.rb
* lib/gitlab/data_builder/**/*.rb
* lib/gitlab/database/**/*.rb
* lib/gitlab/dependency_linker/**/*.rb
* lib/gitlab/diff/**/*.rb
* lib/gitlab/downtime_check/**/*.rb
* lib/gitlab/email/**/*.rb
* lib/gitlab/etag_caching/**/*.rb
Partially addresses gitlab-org/gitlab-ce#47424.
|
|
|
|
Add dbname to MySQL migration GRANT command
See merge request gitlab-org/gitlab-ce!21719
|
|
Add mysql_compatible_index_length to migration helpers
Closes #50253
See merge request gitlab-org/gitlab-ce!21852
|
|
The original code caused Rails to generate invalid SQL. The problem
lays in the `.arel` method in `ActiveRecord::Relation`. When there was
a `limit` on the relation, the `LIMIT` statement was taken over to
Arel, but the value wasn't.
```ruby
relation = Event.limit(2)
relation.to_sql
#=> "SELECT `events`.* FROM `events` LIMIT 2"
relation.arel.to_sql
#=> "SELECT `events`.* FROM `events` LIMIT ?"
```
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/51729
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
`delete_all` doesn't support limit, so you'd need to subquery
that. And instead of subquerying with `where(id: query)`, it's better
to use an `INNER JOIN`. This method also works with MySQL, while
subquerying doesn't (without another layer of subquerying)
Reference:
https://stackoverflow.com/questions/17892762/mysql-this-version-of-mysql-doesnt-yet-support-limit-in-all-any-some-subqu/17892886#17892886
|
|
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
|
|
|
|
it will decide the method for disable statement_timeout upon
per transaction or per session, based on how it's called.
When calling with a block, block will be executed and it will use
session based statement_timeout, otherwise will default to existing
behavior.
|
|
By default statement_timeout will only be enabled during transaction
lifetime, therefore not leaking outside of it.
With `transaction: false` it will set for entire session, but requires
a block to passed. It yields control and cleans up session after block
finishes, also preventing leaking outside of it.
|