518b9a301f
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>
|
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| actioncable | ||
| actionmailbox | ||
| actionmailer | ||
| actionpack | ||
| actiontext | ||
| actionview | ||
| activejob | ||
| activemodel | ||
| activerecord | ||
| activestorage | ||
| activesupport | ||
| ci | ||
| guides | ||
| railties | ||
| tasks | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .rubocop.yml | ||
| .yardopts | ||
| .yarnrc | ||
| Brewfile | ||
| CODE_OF_CONDUCT.md | ||
| codespell.txt | ||
| CONTRIBUTING.md | ||
| Gemfile | ||
| Gemfile.lock | ||
| MIT-LICENSE | ||
| package.json | ||
| rails.gemspec | ||
| RAILS_VERSION | ||
| Rakefile | ||
| README.md | ||
| RELEASING_RAILS.md | ||
| version.rb | ||
| yarn.lock | ||
Welcome to Rails
What's Rails?
Rails is a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.
Understanding the MVC pattern is key to understanding Rails. MVC divides your application into three layers: Model, View, and Controller, each with a specific responsibility.
Model layer
The Model layer represents the domain model (such as Account, Product,
Person, Post, etc.) and encapsulates the business logic specific to
your application. In Rails, database-backed model classes are derived from
ActiveRecord::Base. Active Record allows you to present the data from
database rows as objects and embellish these data objects with business logic
methods.
Although most Rails models are backed by a database, models can also be ordinary
Ruby classes, or Ruby classes that implement a set of interfaces as provided by
the Active Model module.
Controller layer
The Controller layer is responsible for handling incoming HTTP requests and
providing a suitable response. Usually, this means returning HTML, but Rails controllers
can also generate XML, JSON, PDFs, mobile-specific views, and more. Controllers load and
manipulate models, and render view templates in order to generate the appropriate HTTP response.
In Rails, incoming requests are routed by Action Dispatch to an appropriate controller, and
controller classes are derived from ActionController::Base. Action Dispatch and Action Controller
are bundled together in Action Pack.
View layer
The View layer is composed of "templates" that are responsible for providing appropriate representations of your application's resources. Templates can come in a variety of formats, but most view templates are HTML with embedded Ruby code (ERB files). Views are typically rendered to generate a controller response or to generate the body of an email. In Rails, View generation is handled by Action View.
Frameworks and libraries
Active Record, Active Model, Action Pack, and Action View can each be used independently outside Rails. In addition to that, Rails also comes with Action Mailer, a library to generate and send emails; Action Mailbox, a library to receive emails within a Rails application; Active Job, a framework for declaring jobs and making them run on a variety of queuing backends; Action Cable, a framework to integrate WebSockets with a Rails application; Active Storage, a library to attach cloud and local files to Rails applications; Action Text, a library to handle rich text content; and Active Support, a collection of utility classes and standard library extensions that are useful for Rails, and may also be used independently outside Rails.
Getting Started
-
Install Rails at the command prompt if you haven't yet:
$ gem install rails -
At the command prompt, create a new Rails application:
$ rails new myappwhere "myapp" is the application name.
-
Change directory to
myappand start the web server:$ cd myapp $ bin/rails serverRun with
--helpor-hfor options. -
Go to
http://localhost:3000and you'll see: "Yay! You’re on Rails!" -
Follow the guidelines to start developing your application. You may find the following resources handy:
Contributing
We encourage you to contribute to Ruby on Rails! Please check out the Contributing to Ruby on Rails guide for guidelines about how to proceed. Join us!
Trying to report a possible security vulnerability in Rails? Please check out our security policy for guidelines about how to proceed.
Everyone interacting in Rails and its sub-projects' codebases, issue trackers, chat rooms, and mailing lists is expected to follow the Rails code of conduct.
License
Ruby on Rails is released under the MIT License.