This adds a configuration option and code to enable lazy loading of the
schema cache on the connection. If
`config.active_record.lazily_load_schema_cache` is set to `true` then
the Railtie will be completely skipped and the schema cache will be
loaded when the connection is established rather than on boot.
We use this method at GitHub currently in our custom adapter. It enables
us to load schema caches lazily. It also is a solution for schema caches
with multiple databases. The Railtie doesn't know about the other
connections _before_ boot so it can only load the cache for
`ActiveRecord::Base.connection`. Since this loads the cache on
`establish_connection` Rails doesn't need to know anything special about
the connections.
Applications can continue dumping the cache like normal, the change is
only to how the schema cache is loaded. To use the lazy loaded schema
cache a `schema_cache_path` must be set in the database configuration,
otherwise `db/schema_cache.yml` will be used.
Followup questions:
1) Should we deprecate the Railtie?
2) The Railtie does more work than we're doing here because it checks
the version against the current version. I'm not sure we really want
to do this in Rails - we don't do it in ours at GitHub.
Do not suggest that raising `ActiveRecord::Rollback` exception should have a message.
There's no point of adding a message to `ActiveRecord::Rollback` exception because it will be rescued by transaction block and the message will be lost.
Background
---
I recently noticed we had a number of associations in GitHub that would
benefit from having `inverse_of` set, and so I began adding them. I
ended up adding them to virtually every association with a scope, at
which point I wondered whether Rails might be able to automatically find
these inverses for us.
For GitHub, the changes in this commit end up automatically adding
`inverse_of` to 171 of associations that were missing it.
My understanding is that we do not automatically detect `inverse_of` for
associations with scopes because the scopes could exclude the records we
are trying to inverse from. But I think that should only matter if there
is a scope on the inverse side, not on the association itself.
For example:
Scope on has_many
----
```rb
class Post < ActiveRecord::Base
has_many :comments, -> { visible }
end
class Comment < ActiveRecord::Base
belongs_to :post
scope :visible, -> { where(visible: true) }
scope :hidden, -> { where(visible: false) }
end
post = Post.create!
comment = post.comments.hidden.create!
assert comment.post
```
This code leaves `post.comments` in sort of a weird state, since it
includes a comment that the association would filter out. But that's
true regardless of the changes in this commit.
Regardless of whether the comments association has an inverse,
`comment.post` will return the post. The difference is that when
`inverse_of` is set we use the existing post we have in memory, rather
than loading it again. If there is a downside to having the `inverse_of`
automatically set here I'm not seeing it.
Scope on belongs_to
----
```rb
class Post < ActiveRecord::Base
has_many :comments
scope :visible, -> { where(visible: true) }
scope :hidden, -> { where(visible: false) }
end
class Comment < ActiveRecord::Base
belongs_to :post, -> { visible }
end
post = Post.hidden.create!
comment = post.comments.create!
assert_nil comment.post
```
This example is a different story. We don't want to automatically infer
the inverse here because that would change the behavior of
`comment.post`. It should return `nil`, since it's scoped to visible
posts while this one is hidden.
This behavior was not well tested, so this commit adds a test to
ensure we haven't changed it.
Changes
---
This commit changes `can_find_inverse_of_automatically` to allow us to
automatically detect `inverse_of` when there is a scope on the
association, but not when there is a scope on the potential inverse
association. (`can_find_inverse_of_automatically` gets called first with
the association's reflection, then if it returns true we attempt to find
the inverse reflection, and finally we call the method again with the
inverse reflection to ensure we can really use it.)
Since this is a breaking change—specifically in places where code may
have relied on a missing `inverse_of` causing fresh copies of a record
to be loaded—we've placed it behind the `automatic_scope_inversing` flag
(whose name was inspired by `has_many_inversing`). It is set to true for
new applications via framework defaults.
Testing
---
In addition to the inverse association tests, this commit also adds some
cases to a few tests related to preloading. They are basically
duplicates of existing tests, but with lower query counts.
Testing this change with GitHub, the bulk of the failing tests were
related to lower query counts. There were additionally 3 places (2 in
tests and one in application code) where we relied on missing
`inverse_of` causing fresh copies of a record to be loaded.
There's still one Rails test that wouldn't pass if we ran the whole
suite with `automatic_scope_inversing = true`. It's related to
`TaggedPost`, which changes the polymorphic type from the base class
`Post` to the subclass `TaggedPost`.
```rb
class TaggedPost < Post
has_many :taggings, -> { rewhere(taggable_type: "TaggedPost") }, as: :taggable
end
```
Setting the inverse doesn't work because it ends up changing the type
back to `Post`, something like this:
```rb
post = TaggedPost.new
tagging = post.taggings.new
puts tagging.taggable_type
=> TaggedPost
tagging.taggable = post
puts tagging.taggable_type
=> Post
```
I think this is an acceptable change, given that it's a fairly specific
scenario, and is sort of at odds with the way polymorphic associations
are meant to work (they are meant to contain the base class, not the
subclass). If someone is relying on this specific behavior they can
still either keep `automatic_scope_inversing` set to false, or they can
add `inverse_of: false` to the association.
I haven't found any other cases where having the `inverse_of` would
cause problems like this.
Co-authored-by: Chris Bloom <chrisbloom7@gmail.com>
Instrumentation hooks for `write_page.action_controller` and
`expire_page.action_controller` seem to be removed
in https://github.com/rails/rails/pull/7833.
So, subscribers for them are no longer necessary.
When a proc is passed to a callback (either as a condition or as the
callback itself) it is evaluated using instance_exec on the controller
instance. Calling instance_exec creates a new singleton class for the
object, which then will require new inline method caches.
This commit avoids creating the extra controller singleton classes when
:only or :except are passed to a callback.
The ActionView::Helpers::Tags::CheckBox class accepts the `checked` and `include_hidden` options. The documentation for these options is added to the `check_box` methods in the ActionView::Helpers::FormHelper class where they are exposed.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
