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
With the recent changes to OutputBuffer, calling `to_s` is extremely
expensive if the buffer later is concatenated to (if the buffer never
changes it should be relatively inexpensive, as Ruby will share memory).
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.
Followup on https://github.com/rails/rails/pull/45745
`@rendered` is a much better variable for this kind of intermediate
result as that's what is used by DOM assertions.
Right now many helpers have to deal with two modes of operation to
capture view output.
The main one is to swap the `@output_buffer` variable with a new buffer.
But since some view implementations such as `builder` keep a reference
on the buffer they were initialized with, this doesn't always work.
So additionally, the various capturing helpers also record the buffer
length prior to executing the block, and then `slice!` the buffer back
to its original size.
This is wasteful and make the code rather unclear.
Now that `OutputBuffer` is a delegator, I'd like to refactor all this
so that:
- @output_buffer is no longer re-assigned
- A single OutputBuffer instance is used for the entire response rendering
- Instead capturing is done through `OutputBuffer#capture`
Once the above is achieved, it should allow us to enabled Erubi's
`:chain_appends` option and get some reduced template size and some
performance.
Not re-assigning `@output_buffer` will also allow template to access
the local variable instead of an instance variable, which is cheaper.
But more importantly, that should make the code easier to understand
and easier to be compatible with `StreamingBuffer`.
It's really not what it's meant for. `@renderer` is a better use
for this as it's the variable used by the DOM testing helpers.
Ref: https://github.com/rails/rails/pull/45731
Ref: https://github.com/jeremyevans/erubi/pull/33
If the template is compiled with `frozen_string_literals: true`,
then explicitly freezing string is slightly wasteful as it will be
compiled as `opt_str_freeze` instead of a simple `putobject`.
The former has to check wether `String#freeze` was redefined every
time, which while fast is useless extra work.
The `Editor` command helper module was originally extracted from
`CredentialsCommand`, and still includes a help message mentioning
"credentials" and a `rescue` that is specific to encrypted files.
This commit removes those remnants, fully generalizing the `Editor`
module. Additionally, this commit changes `SecretsCommand` to make use
of the `Editor` module.
The i18n gem (https://github.com/ruby-i18n/i18n) has been modified to `freeze`
locale setting values. This could cause the Date helper to not work correctly
under certain conditions. `dup` the configuration values fixes that problem.
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>
