提交 6a6c4c45 编写于 作者: S Sean Griffin

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
上级 4d7b5070
......@@ -41,7 +41,7 @@ def associated_table(table_name)
association = klass._reflect_on_association(table_name)
if association && !association.polymorphic?
association_klass = association.klass
arel_table = association_klass.arel_table
arel_table = association_klass.arel_table.alias(table_name)
else
type_caster = TypeCaster::Connection.new(klass, table_name)
association_klass = nil
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册