Relation#merge checks if the argument is an array and the only possible
returns of build_default_scope is nil or a Relation.
Doing this we can raise an ArgumentError when Relation#merge receive a
nil value.
type.
This allows specific jobs to be tested, while preventing others from
being performed unnecessarily.
Example:
def test_hello_job
assert_performed_jobs 1, only: HelloJob do
HelloJob.perform_later('jeremy')
LoggingJob.perform_later
end
end
An array may also be specified, to support testing multiple jobs.
Example:
def test_hello_and_logging_jobs
assert_nothing_raised do
assert_performed_jobs 2, only: [HelloJob, LoggingJob] do
HelloJob.perform_later('jeremy')
LoggingJob.perform_later('stewie')
RescueJob.perform_later('david')
end
end
end
Fixes#18802.
Trim space and document :only option.
The `&block` form is more than twice as fast as the manual form of
delegation (and is the code I'd rather write anyway). Unfortunately,
it's still twice as slow on MRI. However, this is enough of a hotspot to
justify giving JRuby special treatment.
I can't currently provide benchmarks in the context of Active Record,
since the JDBC adapters still aren't updated for 4.2, but the actual
work performed (assuming it's been read at least once already) will have
nearly the same performance characteristics as
https://gist.github.com/sgrif/b86832786551aaee74de.
The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:
- `attribute`
- Lazy (the attribute will be defined after the schema has loaded)
- Allows either a type object or a symbol
- `define_attribute`
- Runs immediately (might get trampled by schema loading)
- Requires a type object
This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).
A model cannot have two `:belongs_to` with the same exact name, so
we are better off avoiding this code in our examples, which might
mislead users in thinking it's admissible.
[ci skip]
Enable number_to_percentage to keep the number's precision by allowing :precision option value to be nil
Conflicts:
activesupport/CHANGELOG.md
activesupport/lib/active_support/number_helper.rb
activesupport/test/number_helper_test.rb
The `link_to` helper generates an HTML anchor element (consisting of opening and closing anchor tags and an element body). The docs currently state the a link tag is generated (which would indicate a tag like `<link>`, which is another valid HTML tag), so this change clarifies that an anchor element is actually generated.
[ci skip]
These are (potentially, depending on input) called in several places in
both the router, and Active Record. The code also becomes much cleaner.
This results in ~33% performance gain in both methods.
Calculating -------------------------------------
before 15.696k i/100ms
after 19.865k i/100ms
-------------------------------------------------
before 303.064k (± 2.6%) i/s - 1.523M
after 446.734k (± 2.4%) i/s - 2.245M
On Ruby 2.2, a warning will be emitted about states not being copied,
because we're calling `super` from a subclass. We can safely ignore it,
however, since we're converting the result back into a HWIDA
The existing example seems somewhat forced: is it realistic
to have a model that accepts state in its initializer but
considers it has not been changed? By allowing state changes
to happen only via accessors it seems more natural that new
instances are considered to be unchanged (as they are in AR).
[ci skip]
Thor isn't very discerning over whether some content is present when passed
to `inject_into_file`, e.g. a commented out route is detected as being present.
So to prevent people scratching their heads as to why a route hasn't appeared
it's better to fall on the side of having duplicate routes.
While we query the proper columns, we go through normal handling for
converting the value to a primitive which assumes it should use the
table's primary key. If the association specifies a different value (and
we know that we're working with an association), we should use the
custom primary key instead.
Fixes#18813.
