A recent change made it so that when you perform a change column
it will preserve collation on the column rather than nil it out·
which would select the database default. This works fine except in
the case of a binary type. In this case the collation should be
set to nil in the options so that the database default collation
type can be used on the column.
We'll ensure that any consumers that require ddl obtain it by visiting
the schema definition. Consequently, we should also stop visiting the
schema definition in the "schema definition builder" methods -- callers
will need to both build a schema definition, and then visit it using a
SchemaCreation object. This means schema definitions will not be populated
with SQL type information, or any other information that is set when
the definition is visited.
Follow-up to #45735.
Prior to this commit, `drop_enum` could not be reversed when called with
the `if_exists: true` option, because `create_enum` could not accept
options.
This commit fixes that and adds test coverage.
This commit also ensures that reversing `drop_enum` will raise an
`ActiveRecord::IrreversibleMigration` error if no enum values are
specified.
Previously `setup_shared_connection_pool` was called anytime
`setup_fixtures` saw a future connection established. Sometimes those
connections are `nil` but we were setting up the shared pools before
determining that.
This change moves the `setup_shared_connection_pool` into the check for
if we have a connection. The tests that were dealing with these settings
were originally set to not use transacitons. But without this we can't
test the change here so I've updated that as well.
This is an alternate fix to #45769. I realized after opening the PR it
wasn't quite right to skip if we don't have a writing pool config,
because the question is how were we ending up with that anyway? Well the
answer was that we were calling the shared setup in the wrong place.
Fixes#45767
The PR #44931 fell off my radar a few months ago so I decided to add a
test myself to ensure this behavior change is tested. While doing that I
decided to refactor the changes from that PR to make the code a little
cleaner and easier to read.
* Improve #configured_migrate_path logic
This solves two issues:
* `migrations_paths` is an Array, which here gets coerced to a string.
This is fine if it's a single path, but otherwise the generated path
is a concatenation of all the paths. Instead, pick the first one.
* If the `--database` flag is not passed in, fall back to the primary
database's `migrations_paths` entry if available before falling back
to the global default migrate path.
* migrations_paths can be a String, Array, or nil
Define APIs on the MySQL and PostgreSQL connection adapters for building
ChangeColumnDefaultDefinition objects. These provide information on what a
column default change would look like, when called with the same arguments as
would be passed to #change_column_default.
The `remove_check_constraint` method now accepts an `if_exists` option. If set
to true an error won't be raised if the check constraint doesn't exist.
This commit is a combination of PR #45726 and #45718 with some
additional changes to improve wording, testing, and implementation.
Usage:
```ruby
remove_check_constraint :products, name: "price_check", if_exists: true
```
Fixes#45634
Co-authored-by: Margaret Parsa <mparsa@actbluetech.com>
Co-authored-by: Aditya Bhutani <adi_bhutani16@yahoo.in>
Aligns the SQL produced for changing a column default between MySQL and PostgreSQL.
MySQL is currently producing an <ALTER TABLE x CHANGE COLUMN y> query just to
change the default for a column, which is less efficient than using the SET DEFAULT syntax.
Additionally, extracts ChangeColumnDefaultDefinition and moves the SQL generation to the visitor class.
Using `create_or_find_by` in codepaths where most of the time
the record already exist is wasteful on several accounts.
`create_or_find_by` should be the method to use when most of the
time the record doesn't already exist, not a race condition safe
version of `find_or_create_by`.
To make `find_or_create_by` race-condition free, we can search
the record again if the creation failed because of an unicity
constraint.
Co-Authored-By: Alex Kitchens <alexcameron98@gmail.com>
Ref: https://github.com/rails/rails/pull/41659
Mutating the attributes hash requires to workaround the mutation
in `find_or_create_by` etc.
One extra Hash dup is not big deal.
This previously made no difference, but it now saves us reconnecting to
run a ROLLBACK: because we're still inside a transaction at that moment,
we won't be #restorable?.
There's no point attempting to rollback in this case; we can instead
just invalidate the now-lost transaction.
Similarly, even though we can't immediately reconnect for a connection
failure mid-transaction, we can and should drop and prior verification
of the connection: the next out-of-transaction query attempt needs to
fix it, not assume it's working.
Define APIs on the MySQL and PostgreSQL connection adapters for building
ChangeColumnDefinition objects. These provide information on what a
column change would look like, when called with the same arguments as
would be passed to #change_column.
Exposes AlterTable schema definition for adding new columns through new API,
and stores ddl on the schema definition. Refactors existing #add_column method to use
this as an intermediate method to build the create add_column definition.
