An error occurred fetching the project authors.
- 27 Feb, 2020 1 commit
-
-
pbair authored
Change MigrationsHelper#column_for to always raise an error if column being looked for doesn't exist.
-
- 19 Feb, 2020 1 commit
-
-
pbair authored
Display a more detailed error message when a migration references an existing database object (like column or foreign key) that doesn't exist.
-
- 05 Feb, 2020 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 29 Jan, 2020 1 commit
-
-
Rémy Coutable authored
-
- 28 Jan, 2020 1 commit
-
-
Jason Goodman authored
Backfill iid for existing feature flags Make new feature flags save an iid
-
- 22 Jan, 2020 1 commit
-
-
Adam Hegyi authored
-
- 15 Jan, 2020 1 commit
-
-
Andreas Brandl authored
This is to support queries like the following: ```sql SELECT "projects".* FROM "projects" WHERE (EXISTS ( SELECT 1 FROM "project_authorizations" WHERE "project_authorizations"."user_id" = 1562869 AND (project_authorizations.project_id = projects.id)) OR projects.visibility_level IN (10, 20)) AND "projects"."pending_delete" = FALSE ORDER BY "projects"."updated_at" DESC, "projects"."id" DESC LIMIT 20 OFFSET 0; ``` With this change, we add indexes for all order_by options. The regularly sorted index (`asc, asc`) has the common name whereas the one with `desc, desc` is optimized for API calls. It may be subject to removal later (see https://gitlab.com/gitlab-org/gitlab/issues/195881). Relates to https://gitlab.com/gitlab-org/gitlab/issues/36390. A similar MR for unauthenticated calls is https://gitlab.com/gitlab-org/gitlab/merge_requests/22784.
-
- 08 Jan, 2020 1 commit
-
-
charlieablett authored
- Checks for foreign key name, infers if missing - Designed to be standalone method specifically for calling after a foreign key has been created, but can't be validated yet, usually because there's data to be cleaned up - Add helpful error message
-
- 06 Jan, 2020 2 commits
-
-
charlieablett authored
- Use `let` instead of local variable - Add comment to make the consequences of `validate: false` explicit
-
charlieablett authored
Add `validate: false` option for adding concurrent foreign key. This allows the table lock to be held for a minimal amount of time while still performing the checks that `add_concurrent_foreign_key` performs for adding a foreign key to a table that may contain invalid data, allowing us to put off any validation to a different time.
-
- 17 Dec, 2019 1 commit
-
-
Arturo Herrero authored
We are going to introduce a maximum number of webhooks per project. This limit will be configured depending on the GitLab plan.
-
- 02 Dec, 2019 1 commit
-
-
manojmj authored
-
- 27 Nov, 2019 2 commits
- 01 Nov, 2019 1 commit
-
-
Andreas Brandl authored
It's not needed anymore as we require Postgres >= 9.6 now
-
- 05 Sep, 2019 2 commits
-
-
Ash McKenzie authored
RailsHelpers.stub_rails_env takes care of stubbing Rails.env
-
Ash McKenzie authored
RailsHelpers.stub_rails_env takes care of stubbing Rails.env
-
- 25 Aug, 2019 2 commits
-
-
Reuben Pereira authored
- Also add helper to undo rename_column_concurrently.
-
Reuben Pereira authored
- Also add helper to undo rename_column_concurrently.
-
- 24 Aug, 2019 1 commit
-
-
Reuben Pereira authored
- 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.
-
- 26 Jul, 2019 1 commit
-
-
Thong Kuah authored
Using the sed script from https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
-
- 23 Jul, 2019 2 commits
-
-
Nick Thomas authored
None of this code can be reached any more, so it can all be removed
-
Nick Thomas authored
None of this code can be reached any more, so it can all be removed
-
- 18 Jul, 2019 1 commit
-
-
Alex Kalderimis authored
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.
-
- 28 Jun, 2019 1 commit
-
-
Jason Goodman authored
-
- 19 Jun, 2019 2 commits
-
-
Stan Hu authored
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21497, we migrated all project import data into a separate table, `project_import_data`. In addition, we also added: ``` ignore_column :import_status, :import_jid, :import_error ``` In https://gitlab.com/gitlab-com/gl-infra/production/issues/908, we observed some of these `import_error` columns consumed megabytes of error backtraces and caused slow loading of projects whenever a `SELECT * from projects` query loaded the row into memory. Since we have long migrated away from these columns, we can now drop these columns entirely.
-
Stan Hu authored
In https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21497, we migrated all project import data into a separate table, `project_import_data`. In addition, we also added: ``` ignore_column :import_status, :import_jid, :import_error ``` In https://gitlab.com/gitlab-com/gl-infra/production/issues/908, we observed some of these `import_error` columns consumed megabytes of error backtraces and caused slow loading of projects whenever a `SELECT * from projects` query loaded the row into memory. Since we have long migrated away from these columns, we can now drop these columns entirely.
-
- 17 Jun, 2019 2 commits
-
-
Yorick Peterse authored
This is necessary for backporting the EE schema to ensure backported foreign keys use the same key names.
-
Yorick Peterse authored
This is necessary for backporting the EE schema to ensure backported foreign keys use the same key names.
-
- 14 Dec, 2018 2 commits
-
-
Jasper Maes authored
-
Jasper Maes authored
-
- 14 Nov, 2018 2 commits
-
-
Jan Provaznik authored
We want to run CI with rails 4 for a short-term (until we are sure that we will ship with rails 5). The problem is that rails 4 can not handle rails 5 schema.rb properly - specifically `t.index` directive can not handle multiple indexes on the same column. Because combination of rails 4 + rails 5 schema will be used only in CI for a short-term, we can just ignore these incompatibility failures. This patch adds `rails5` helper for specs.
-
Jan Provaznik authored
We want to run CI with rails 4 for a short-term (until we are sure that we will ship with rails 5). The problem is that rails 4 can not handle rails 5 schema.rb properly - specifically `t.index` directive can not handle multiple indexes on the same column. Because combination of rails 4 + rails 5 schema will be used only in CI for a short-term, we can just ignore these incompatibility failures. This patch adds `rails5` helper for specs.
-
- 11 Aug, 2018 1 commit
-
-
Gabriel Mazetto authored
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.
-
- 10 Aug, 2018 2 commits
-
-
Gabriel Mazetto authored
-
Gabriel Mazetto authored
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.
-
- 26 Jun, 2018 1 commit
-
-
Sean McGivern authored
This works the same way as change_column_type_using_background_migration, but for renaming a column. It takes a table, not a relation, to match its concurrent counterpart. Also, generalise the cleanup migrations to reduce code duplication.
-
- 28 Mar, 2018 1 commit
-
-
Bob Van Landuyt authored
This will use the same query as `\di` to find an index on postgresql.
-
- 20 Mar, 2018 2 commits
-
-
Andreas Brandl authored
Closes #43887.
-
Andreas Brandl authored
Index creation does not have an effect if the index is present already. Index removal does not have an affect if the index is not present. This helps to avoid patterns like this in migrations: ``` if index_exists?(...) remove_concurrent_index(...) end ```
-