1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/activerecord/lib
Sean Griffin 6a6c4c4591 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
2015-06-27 18:14:38 -06:00
..
active_record Revert the behavior of association names and where to be closer to 4.2 2015-06-27 18:14:38 -06:00
rails/generators [ci skip] Correct grammar, add docs to ActiveRecord migration generator 2015-04-28 13:34:13 -07:00
active_record.rb Autoload ActiveRecord::RecordInvalid 2015-06-18 18:36:16 -03:00