This will ensure we attempt to render an empty collection, meaning we
don't actually render anything at all. Allowing `nil` or a falsey value
through results in calling `render_partial` rather than
`render_collection`, which isn't what we want.
An optimization was introduced in
27f4ffd11a
which tried to `#to_ary` the collection to prevent unnecessary queries
for ActiveRecord scopes/relations. If the given collection did not
respond to `#to_ary`, and empty collection was returned. That meant you
couldn't use collections built from `Enumerator` nor `Enumerable`.
With this change, `#collection_from_options` will attempt the
optimization, but fall back to passing along the given collection,
as-is.
Previously we had primarily tested the behavior of these attributes by
calling `.new`, allowing this to slip through the cracks. There were a
few ways in which they were behaving incorrectly.
The biggest issue was that attempting to read the attribute would
through a `MissingAttribute` error. We've corrected this by returning
the default value when the attribute isn't backed by a database column.
This is super special cased, but I don't see a way to avoid this
conditional. I had considered handling this higher up in
`define_default_attribute`, but we don't have the relevant information
there as users can provide new defaults for database columns as well.
Once I corrected this, I had noticed that the attributes were always
being marked as changed. This is because the behavior of
`define_default_attribute` was treating them as assigned from
`Attribute::Null`.
Finally, with our new implementation, `LazyAttributeHash` could no
longer be marshalled, as it holds onto a proc. This has been corrected
as well. I've not handled YAML in that class, as we do additional work
higher up to avoid YAML dumping it at all.
Fixes#25787Close#25841
In Ruby ^ and $ mean start and end of *line*.
A regexp that validates an email should not check if
some line of the string looks like an email, and maybe
be surrounded by the entire Joyce's Ulysses. What the
regexp has to check is if the string itself looks like
an email.
This validator is used only in tests, the ^/$ anchors
implied no risk.
`StatementCache` is hard-coded in `cacheable_query` and be passed
`visitor` and `collector` from connection adapter. Simply it is
enough to pass a collected value.
* Following tests were failing on Ruby edge 2.4 version -
- RelationTest#test_update_all_with_joins_and_offset_and_order:
- RelationTest#test_update_all_with_joins_and_offset:
- BasicsTest#test_no_limit_offset:
- CalculationsTest#test_offset_is_kept:
- ActiveRecord::CollectionCacheKeyTest#test_cache_key_for_queries_with_offset_which_return_0_rows:
- FinderTest#test_third_to_last:
* As Arel 7.1 supports Integer unification after https://github.com/rails/arel/pull/437 we can use it.
It all started noticing some foo.method({ ... }) method calls
in passing. This is a whole pass modernizing this file.
While some string literals are edited where I touched code,
this pass does not uniformizes quotes. A ton are left untouched
on purposes. We have no defined style.
Code like `render(topics) => render("topics/topic")` adds confusion
for the readers. On first impression, that code feels like hash kind
of data, but it's not. So make it more clear and meaningful.
The merging of the 'defaults' option was moved up the stack in e852daa
This allows us to see where these options originate from the standard
HttpHelpers (get, post, patch, put, delete)
Unfortunately this move didn't incorporate the 'root' method, which has
always allowed the same 'defaults' option before.
AEAD modes like `aes-256-gcm` provide both confidentiality and data authenticity, eliminating the need to use MessageVerifier to check if the encrypted data has been tampered with.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
For consistency mainly.
Also, some have a name that could make the reader think they
enforce the opposite of what they do, because the default is
not visible there.
I dropped the version constraint in web-console with the idea it will be
easier to upgrade the console between Rails releases. However, issues
like #25899 started popping up.
I'm reintroducing the constraint, but this time, I don't set an upper
limit to the major version. This will keep the web-console in a version
that always works for the current Rails version and can be easily
upgraded to the last one with `bundle update`.
We may need to backport this for Rails 5.0.1.
Fixes#25899.
