Changed partial rendering to allow collections which don't implement
An optimization was introduced in 27f4ffd which will call
With this change,
This transforms for instance scoped objects into arrays and avoid unneeded queries [#5958 state:committed]
An optimization was introduced in 27f4ffd 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.
I wonder, will that have the desired consequence? More things implement
My understanding of the original optimization was to cause an ActiveRecord scope to evaluate and then prevent extra DB calls. In that case, the
Yeah, the original intention was basically to pre-buffer the
Otherwise we're likely to run into an issue with our need for
As you note, we know it's not infinite, because we know we're about to call
We can safely assume we're not dealing with an infinite collection as we're about to call `each` on it and collect the results until it terminates on its own. Given that, `to_a` is implemented by the normal Array-like objects, and less Array-like objects like `Enumerator` and `Enumerator::Lazy`.
The Rails PR that introduced the backwards-incompatible change that prompted this: rails/rails#25912 rails/rails@87899cf The Rails changelog entry is under 5.0.1.rc1: https://github.com/rails/rails/blob/v5.0.1/actionview/CHANGELOG.md#rails-501rc1-december-01-2016 See also #508
@glebm Yeah, I think I'm okay with that. I'm not sure
Either one of those alone might be insufficient to justify a change on a stable branch, but combined, I don't think it's worth trying both methods.
Happy to revisit if this turns out to be a wider problem, though.