In 7a26f2625533a0d45c0a1efbd264d3eb7462ee7b the usage of
`ActiveSupport::Deprecation.warn` in `DBconsoleCommand` was replaced with
`Rails.deprecator.warn`, which is already required by Rails::Command.
The sole purpose of `ActionController::Rendering#_normalize_args` is to
store the given block in `options[:update]`. This behavior was added
long ago in 6923b392b740f2346326634532b40cf24a0f26ef (as [part of
`ActionController::Base#_normalize_options`][part-of]) to support RJS.
Rails no longer supports RJS, so this override is no longer necessary.
[part-of]: 6923b392b7 (diff-febf2f89e7c197d6a9a7077c96031c68b2b7ac4d8ce7ec634de92b164e5f69adR100)
Follow-up to e9bc620f786d7da9afb82ec13ca3ec249f856c0c and
3ec629784cac7a8b518feb402475153465cd8e96.
`assert_not_deprecated` without any arguments will test against
`ActiveSupport::Deprecation.instance`, whereas `Enumerable#sum` would
use `ActiveSupport.deprecator`. However, the `Enumerable#sum` override
was removed in 3ec629784cac7a8b518feb402475153465cd8e96, so we can
simply remove `assert_not_deprecated`.
Given a model with a composite primary key, the `query_constraints_list`
should equal the `primary_key` value to enable capabilities managed by
`query_constraints_list` such as `destroy`, `update`, `delete` and others.
Given a model with a composite primary key:
```ruby
class Order < ActiveRecord::Base
self.primary_key = [:shop_id, :id]
end
```
`ActiveRecord::Base#id` method will return an array of values for every
column of the primary key.
```ruby
order = Order.create!(shop_id: 1, id: 2)
order.id # => [1, 2]
```
The `id` column is accessible through the `read_attribute` method:
```ruby
order.read_attribute(:id) # => 2
```
Currently we use both Thor and Rake for `bin/rails` commands.
We eventually want to get all the built-ins task promoted to Thor Commands.
This migrates the `about` task to Thor.
```ruby
add_unique_key :sections, [:position], deferrable: :deferred, name: "unique_section_position"
remove_unique_key :sections, name: "unique_section_position"
```
See PostgreSQL's [Unique Constraints](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-UNIQUE-CONSTRAINTS) documentation for more on unique constraints.
By default, unique constraints in PostgreSQL are checked after each statement.
This works for most use cases, but becomes a major limitation when replacing
records with unique column by using multiple statements.
An example of swapping unique columns between records.
```ruby
old_item = Item.create!(position: 1)
new_item = Item.create!(position: 2)
Item.transaction do
old_item.update!(position: 2)
new_item.update!(position: 1)
end
```
Using the default behavior, the transaction would fail when executing the
first `UPDATE` statement.
By passing the `:deferrable` option to the `add_unique_key` statement in
migrations, it's possible to defer this check.
```ruby
add_unique_key :items, [:position], deferrable: :immediate
```
Passing `deferrable: :immediate` does not change the behaviour of the previous example,
but allows manually deferring the check using `SET CONSTRAINTS ALL DEFERRED` within a transaction.
This will cause the unique constraints to be checked after the transaction.
It's also possible to adjust the default behavior from an immediate
check (after the statement), to a deferred check (after the transaction):
```ruby
add_unique_key :items, [:position], deferrable: :deferred
```
PostgreSQL allows users to create a unique constraints on top of the unique
index that cannot be deferred. In this case, even if users creates deferrable
unique constraint, the existing unique index does not allow users to violate uniqueness
within the transaction. If you want to change existing unique index to deferrable,
you need execute `remove_index` before creating deferrable unique constraints.
*Hiroyuki Ishii*
Currently we use both Thor and Rake for `bin/rails` commands.
We eventually want to get all the built-ins task promoted to Thor Commands.
This migrates the secret task to Thor.
`"lts"` isn't supported by all version managers, and even if
it was, it's a moving target, so it might build differently
on different machines based on how the version manager
refresh it's definition list.
ref: https://github.com/rails/rails/issues/47435#issuecomment-1436530001
- `rails new APP_PATH --dev` works fine.
- `rails new --dev APP_PATH` does not work.
For most other flags, putting the APP_PATH before or after the flags has the same effect. It's just the prelease ones that have issues, because we have to rengerate the command so as to call `bundle exec rails new ...` a second time.
Prior to this PR, the command that was being called was `bundle exec rails new APP_PATH APP_PATH`, and that doesn't work. Now it will get called as `bundle exec rails new APP_PATH --dev APP_PATH` which is fine.
I haven't been able to find a way to write an automated test for this, but you can use the replication steps in https://github.com/rails/rails/issues/47435 to verify that the issue is fixed.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
Shopify is implementing a custom ActiveRecord adapter to integrate
with [Vitess](https://vitess.io/), and we would like to overload the
`valid_{column,table}_definition_options` methods and add
additional valid options for schema migrations.
For example:
```ruby
module ActiveRecord
module ConnectionAdapters
class VitessMysql2Adapter < Mysql2Adapter
...
def valid_table_definition_options
super + [:skip_vschema_migrations, :sharding_keys, :auto_increment]
end
def valid_column_definition_options
super + [:skip_vschema_migrations, :sharding_keys, :auto_increment]
end
end
end
end
```
This is the simplest possible change and factors out the various `valid_{table,column,primary_key}_definition_options` to be a public
method on an adapter instance.
This test was leaving behind the directory and was never verifying the
file existed after dump was called. We can't use a tempfile because it
will be created automatically and this is testing that
`SchemaCache#open` will create the file if it doesn't exist.
Current Dockerfile generated by Rails runs as a non-root user
which prevents modification of the operating system but leaves
wide open all gems and the application itself.
This change locks down the application gems and only opens up
access to the following directories: db, log, storage, tmp
This is a even more secure alternative to
https://github.com/rails/rails/pull/47580
We should properly hex-encode binary strings for SQLite3 and MySQL.
For e.g. MySQL, _not_ doing that _may_ work, but it will also
produce database warnings.
