Thor, the generator USAGE files and some command USAGE files use
identation to divide the USAGE files into separate sections.
Indentation is also used to describe the options that can be passed
to the commands.
For consistency we should use the same formatting for all commands.
As Thor and most USAGE files already use identation it's a smaller
change to use identation for all commands.
For the examples extra identation is used. This makes them stand out
more allows removing the backticks which make it easier to copy the code
examples.
__Before (example for runner)__
```console
bin/rails runner --help
Commands:
bin/rails runner [<'Some.ruby(code)'> | <filename.rb> | -] # Run Ruby code in the context of your application
bin/rails runner:help [COMMAND] # Describe available commands or one specific command
Options:
-e, [--environment=ENVIRONMENT] # The environment to run `runner` in (e.g. test / development / production).
Examples:
Run `puts Rails.env` after loading the app:
bin/rails runner 'puts Rails.env'
Run the Ruby file located at `path/to/filename.rb` after loading the app:
bin/rails runner path/to/filename.rb
Run the Ruby script read from stdin after loading the app:
bin/rails runner -
You can also use the runner command as a shebang line for your executables:
#!/usr/bin/env /path/to/weblog/bin/rails runner
Product.all.each { |p| p.price *= 2 ; p.save! }
```
__After__
```console
bin/rails runner --help
Usage:
bin/rails runner [<'Some.ruby(code)'> | <filename.rb> | -]
Options:
-e, [--environment=ENVIRONMENT] # The environment to run `runner` in (e.g. test / development / production).
Run Ruby code in the context of your application
Description:
The Rails `runner` allows running Ruby code in the context of your application.
Examples:
Run `puts Rails.env` after loading the app:
bin/rails runner 'puts Rails.env'
Run the Ruby file located at `path/to/filename.rb` after loading the app:
bin/rails runner path/to/filename.rb
Run the Ruby script read from stdin after loading the app:
bin/rails runner -
You can also use the runner command as a shebang line for your executables:
#!/usr/bin/env /path/to/weblog/bin/rails runner
Product.all.each { |p| p.price *= 2 ; p.save! }
```
Initial implementation falls back to `primary_key.is_a?(Array)` so
it can be immediately used in place of direct `is_a?` checks.
Though implementation may be changed to rely on a pre-initialized
`@composite_primary_key` ivar in the future.
`ActiveRecord::FinderMethods#find` now supports passing sets of
composite primary key values like:
```ruby
Cpk::Book.find([1, 1])
Cpk::Book.find([[1, 1]])
Cpk::Book.find([1, 1], [1, 2])
Cpk::Book.find([[1, 1], [1, 2]])
```
and treats values as values of the composite primary key columns but
only for models with the `primary_key` being an `Array`.
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 `restart` task to Thor.
With this change it also possible to restart outside the application
directory:
```bash
blog/bin/rails restart
```
Co-authored-by: Hartley McGuire <skipkayhil@gmail.com>
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
The codepaths related to destroying associations asynchronously now
consider when query constraints are present. In most cases, this means
interpreting the primary key as an array of columns, and identifying
associated records by a tuple of these columns, where previously this
would've been a single ID. In each of the callsites, we use branching.
This is done to maintain backwards compatibility and ensure the
signature of the destroy job remains stable: it has consumers outside of
Rails.
Follow-up to #47208.
When using Rake-style CLI arguments, `Rake::Application#top_level_tasks`
will return the full task invocation rather than the parsed task name.
For example, when running `rake foo[bar] baz[qux]`, `top_level_tasks`
will return `["foo[bar]", "baz[qux]"]` rather than `["foo", "baz"]`.
Therefore, we must extract the task name before checking existence.
Returning `self` and `db_config` from `resolve_config_for_connection` is
hold over from legacy behavior when we returned `self.name` or
`Base.name` rather than just `self`. We can simplify this by passing
`self` directly` to the handlers `establish_connection`.
By default, exclude constraints in PostgreSQL are checked after each statement.
This works for most use cases, but becomes a major limitation when replacing
records with overlapping ranges by using multiple statements.
```ruby
exclusion_constraint :users, "daterange(valid_from, valid_to) WITH &&", deferrable: :immediate
```
Passing `deferrable: :immediate` checks constraint after each statement,
but allows manually deferring the check using `SET CONSTRAINTS ALL DEFERRED`
within a transaction. This will cause the excludes to be checked after the transaction.
It's also possible to change the default behavior from an immediate check
(after the statement), to a deferred check (after the transaction):
```ruby
exclusion_constraint :users, "daterange(valid_from, valid_to) WITH &&", deferrable: :deferred
```
*Hiroyuki Ishii*
Currently we use both Thor and Rake for `bin/rails` commands.
We eventually want to get all the built-in tasks promoted to Thor Commands.
This migrates the `middleware` task to Thor.
There is a potential DOM based cross-site scripting issue in rails-ujs
which leverages the Clipboard API to target HTML elements that are
assigned the contenteditable attribute. This has the potential to occur
when pasting malicious HTML content from the clipboard that includes
a data-method, data-disable-with or data-remote attribute.
[CVE-2023-23913]
