config.active_jobs.verbose_enqueue_logs was [added][1] to the
development.rb template, but it was put inside the skip-active-record
block. This means that it will be included in generated development.rb
even when Active Job is skipped.
This commit fixes this issue by moving it outside of the
skip-active-record check and into its own skip-active-job check.
[1]: f6d56fed27cfd11aa7161129e2c59a972f90b76b
Most of the support here is in implementing how to correctly substitute
multiple values in place of one, for composite caes. In composite cases,
it's not sufficient to hash a label into a single integer value.
Instead, we build an API that accepts a single label, and a list of
columns that we'd like to map to. The algorithm used internally is very
similar to #identify, with an additional bit shift and modulo to cycle
the hash and ensure it doesn't exceed a max.
This fixes `ids_writer` so that it can handle a composite primary key.
Using a CPK model associated with a non-CPK model was working correctly
(which I added a test for). Using a CPK model associated with another
CPK model was not working correctly. It now takes it into account to
write the correct ids.
While working on `ids_reader` I found that `pluck` is not working for
CPK because it's passing an array of attributes and that's not supported
by `disallow_raw_sql!`. I chose to call `flatten` in `pluck` but not
conditionally because this seems like it could be a problem elsewhere as
well. This fixes pluck by CPK overall and fixes a test in the
calculations test file.
Given a model associated with a composite primary key by `id` attribute,
for example:
```ruby
Order.primary_key = [:shop_id, :id]
OrderAgreement.primary_key = :id
OrderAgreement.belongs_to :order, primary_key: :id
```
Assigning `order` to an `OrderAgreement` object will replace the
`order_id` foreign key:
```ruby
order = Order.last # => #<Order id: 1, shop_id: 2>
order_agreement = OrderAgreement.new(order: order).save
order_agreement.order_id # => 1
```
Given a model associated with a composite primary key by `id` attribute,
for example:
```ruby
Order.primary_key = [:shop_id, :id]
OrderAgreement.primary_key = :id
Order.has_many :order_agreements, primary_key: :id
```
Accessing the association should perform queries using
the `id` attribute value and not the `id` as Order's composite primary key.
```ruby
order = Order.last # => #<Order id: 1, shop_id: 2>
order.order_agreements.to_a
```
#47800 refactored how `Relation#none` worked, and one side effect of this change was that if you had an association like this:
`has_many :comments_none, ->(post) { none }, class_name: "Comment”`
reading the association caused a query to happen, despite the `none` in the passed in scope.
As it turns out, this is because the association performs a merge of the two scopes, and the `@none` instance variable wasn’t getting copied over to the merged scope, so the upfront guard clause checking `@none` in `#exec_main_query`.
Updating the `Merger` object to add a check for null relations and call `none!` ensures the query doesn’t run in this particular scenario.
Follow-up to #46049 and #47354.
Since `Rails.deprecator` is now a new `ActiveSupport::Deprecation`
instance instead of `ActiveSupport::Deprecation.instance`, it makes
sense to register it as `Rails.application.deprecators[:railties]`
instead of `Rails.application.deprecators[:rails]`.
Explicitly set the fully qualified reference name to avoid issues in
environments which set a different default registry.
The registry at registry.docker.com is dual stack-compatible.
When 8b2f57dc6f was
introduced it broke delegation of a method with implicit block like this:
```ruby
class Foo
def self.bar
yield
end
end
class Bar
delegate :bar, to: Foo
end
Bar.new.bar { } # raises LocalJumpError: no block given (yield)
```
It happens because it's impossible to detect a method with implicit block and
we rely on method's parameters when we generate delegated methods.
I've found only one solution to this issue: we always generate a method that explicitly accepts
block. It kind of makes sense since evey Ruby method accepts block implicitly anyway.
Fixes https://github.com/rails/rails/issues/47624
