Before rails-ujs was [updated][1] from coffeescript to es6, the lint
task ran eslint on both the coffee files and the ujs test files. When it
was updated to lint the new es6 files, the test files were erroneously
left out.
This commit fixes the task to lint the rails-ujs test files and fixes
the lint errors that have been introduced since.
[1]: 7d116c93cf6cf2470600860c4c17417df7768c34
Given an association defined with composite query constraints like:
```ruby
BlogPost.has_many :comments, query_constraints: [:blog_id, :blog_post_id]
```
it is possible to query blog posts by whole `comments` objects like:
```ruby
comments = Comment.first(2)
BlogPost.where(comments: comments).to_a
```
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*
