Before this change did_you_mean shows partial paths like `animals/_partial`,
but adding that to your render call in a view like `<%= render 'animals/_partial' %>`
will still be missing as rails will search for the template `animals/__partial`.
We can provide the user a easier copy/paste correction if we don't tell them about the underscore.
This also reduces the candidates to only return partials if you are
looking for a partial and only look for non-templates when you are not
looking for a template.
This updates ActionView::CacheExpiry to hold a lock while inside the
executor (ie. inside a request) and to only clear caches when that is
done.
This is done using Concurrent::ReadWriteLock. This allows any number
of parallel requests to hold the read lock, but once we detect a change
and begin to acquire the write lock, all future requests will be
blocked.
In a multiple database application, associations can't join across
databases. When set, this option tells Rails to make 2 or more queries
rather than using joins for associations.
Set the option on a has many through association:
```ruby
class Dog
has_many :treats, through: :humans, disable_joins: true
has_many :humans
end
```
Then instead of generating join SQL, two queries are used for `@dog.treats`:
```
SELECT "humans"."id" FROM "humans" WHERE "humans"."dog_id" = ? [["dog_id", 1]]
SELECT "treats".* FROM "treats" WHERE "treats"."human_id" IN (?, ?, ?) [["human_id", 1], ["human_id", 2], ["human_id", 3]]
```
This code is extracted from a gem we use internally at GitHub which
means the implementation here is used in production daily and isn't
experimental.
I often get the question "why can't Rails do this automatically" so I
figured I'd include the answer in the commit. Rails can't do this
automatically because associations are lazily loaded. `dog.treats` needs
to load `Dog`, then `Human` and then `Treats`. When `dog.treats` is
called Rails pre-generates the SQL that will be run and puts that
information into a reflection object. Because the SQL parts are pre-generated,
as soon as `dog.treats` is loaded it's too late to skip a join. The join
is already available on the object and that join is what's run to load
`treats` from `dog` through `humans`. I think the only way to avoid setting
an option on the association is to rewrite how and when the SQL is
generated for associations which is a large undertaking. Basically the
way that Active Record associations are designed, it is currently
impossible to have Rails figure out to not join (loading the association
will cause the join to occur, and that join will raise an error if the
models don't live in the same db).
The original implementation was written by me and Aaron. Lee helped port
over tests, and I refactored the extraction to better match Rails style.
Co-authored-by: Lee Quarella <leequarella@gmail.com>
Co-authored-by: Aaron Patterson <aaron@rubyonrails.org>
* Add `Enumerable#sole`, from `ActiveRecord::FinderMethods#sole`
* distinguish single-item Enumerable and two-item with nil last
Add a test for same.
* add symmetry, against rubocop's wishes
Ultimately it's exactly the same semantic that was implemented
using `superclass`, except it avoid recursion and benefit from
method cache, so much faster the longer the inheritance chain.
The use of an alias_method chain is unfortunate, but I don't
see any alternative to cast the provided value to string.
Running tests in parallel with processes wasn't failing fast when the
option was enabled. The problem was that even when the reporter raised
the `Interrupt` exception, the queue was not emptied, so workers keep
processing jobs as if nothing happened.
This patch basically intercepts the `Interrupt` exception that may
come from the reporter, and tells the server to clear the jobs queue,
so that it can continue the shutdown process as usual. The exception
must then continue its journey so that the backtrace is displayed.
When saving a record, autosave adds callbacks to save its' associations.
Since the associations can have similar callbacks for the inverse,
endless loops could occur.
To prevent these endless loops, the callbacks for `has_many` and
`belongs_to` are defined as methods that only execute once.
This is implemented in the `define_non_cyclic_method` method.
However, this wasn't used for the `has_one` callbacks.
While `has_one` association callbacks didn't result in endless loops,
they could execute multiple times.
For example for a bidirectional `has_one` with autosave enabled,
the `save_has_one_association` gets called twice:
class Pirate < ActiveRecord::Base
has_one :ship, autosave: true
def save_has_one_association(reflection)
@count ||= 0
@count += 1 if reflection.name == :ship
super
end
end
class Ship < ActiveRecord::Base
belongs_to :pirate, autosave: true
end
pirate = Pirate.new(catchphrase: "Aye")
pirate.build_ship(name: "Nights Dirty Lightning")
pirate.save!
# this returns 2 instead of 1.
assert_equal 1, pirate.instance_variable_get(:@count)
This commit changes `has_one` autosave callbacks to be non-cyclic as
well. By doing this the autosave callback are made more consistent for
all 3 cases: `has_many`, `has_one` and `belongs_to`.
The return type was changed in the PR #41704 after addition of mode
option. The current documentation is misleading since
documentation puropose strict_loading! would return boolean whereas
it returns the current mode set.
I can across this issue while debugging issue: #41827 and thought
this should be brought to the attention.
PR fixes the issue and would always return boolean based on
strict_loading is enabled or disabled.
```
user.strict_loading! # => true
user.strict_loading!(false) # => false
user.strict_loading!(mode: :n_plus_one_only) # => true
```
