diff options
author | Sean Griffin <sean@thoughtbot.com> | 2015-06-27 18:07:01 -0600 |
---|---|---|
committer | Sean Griffin <sean@thoughtbot.com> | 2015-06-27 18:14:38 -0600 |
commit | 6a6c4c459106e2d9b76dd1233133a2bf30866ab0 (patch) | |
tree | 0da02bd15d01688ac3aac961f41b37c01c3b3472 /actionmailer/MIT-LICENSE | |
parent | 4d7b50707376b09188b545043e893f275dfd84e0 (diff) | |
download | rails-6a6c4c459106e2d9b76dd1233133a2bf30866ab0.tar.gz rails-6a6c4c459106e2d9b76dd1233133a2bf30866ab0.tar.bz2 rails-6a6c4c459106e2d9b76dd1233133a2bf30866ab0.zip |
Revert the behavior of association names and `where` to be closer to 4.2
With this change, we will always assume the association name is the same
as the table it's referencing. This is subtly different than treating
the hash key passed to `where` as the table name, as it still allows the
class referenced by the association to provide additional type
information.
After exploring several possible solutions to the ambiguity problem, I
do not think there is a short term answer that will maintain backwards
compatibility.
This change will make it so the following code does not work:
class User
has_many :approved_posts, -> { where(approved: true) }, class_name: "Post"
end
User.where(approved_posts: { id: 1 })
But prevents potential ambiguity and collision as demonstrated in [this
gist](https://gist.github.com/senny/1ae4d8ea7b0e269ed7a0).
Unfortunately, truely solving this requires significantly
re-architecting this code, so that what is currently represented as an
`Arel::Attribute` is instead another data structure that also references
the association it is representing, so we can identify the proper table
name for aliasing when we construct the final tree.
While I'd still like to accomplish that in the long run, I don't think
I'll be able to get there in time for Rails 5 (since I'm not full time
OSS any more, and this is several weeks worth of work). I'm hoping to
achieve this for Rails 5.1.
Fixes #20308
Diffstat (limited to 'actionmailer/MIT-LICENSE')
0 files changed, 0 insertions, 0 deletions