This project is archived and is in readonly mode.
Support join based eagerloading of has_one through associations
-
Tarmo Tänav
Added another patch on top of this one that fixes join-based eager loading of has_one associations with more than one matching record and an order.
-
Repository
- State changed from new to resolved
(from [6ae0a0557d5e2859e359275b5feebb7e3c13271c]) Load the first and not the last has_one result when doing join-based eager loading
This matters when the has_one is defined with an order in which case there is an expectation that the first one will be loaded.
[#904 state:resolved]
Signed-off-by: Jeremy Kemper jeremy@bitsweat.net http://github.com/rails/rails/co...
-
Repository
(from [a445cdd8840c4e99c40c6d5b15ab380d39a56be3]) Load the first and not the last has_one result when doing join-based eager loading
This matters when the has_one is defined with an order in which case there is an expectation that the first one will be loaded.
[#904 state:resolved]
Signed-off-by: Jeremy Kemper jeremy@bitsweat.net http://github.com/rails/rails/co...
-
Fotos Georgiadis
- Importance changed from to
Hi,
we just got bitten by the change done in http://github.com/rails/rails/commit/a445cdd
This breaks nested has_many associations as illustrated in ticket #5623.
As we understand it this patch was added to cover cases like this (taken from post.rb test model):
has_one :last_comment, :class_name => 'Comment', :order => 'id desc'Well, this seems like an abuse of the has_one association and can definitely be written in better ways, which is something we should be promoting, like:
has_many :comments do def last find(:first, :order => "id DESC") end endOne could argue that providing an :order option for has_one relations doesn't make any sense at all. A has_one denotes that there is only one record on the other side of the association and "ordering" it doesn't look right. Perhaps tho it serves another purpose we seem to neglect...
We propose a reversal of the patch done in http://github.com/rails/rails/commit/a445cdd, since it breaks legitimate use cases (in a way that it's easy to miss it returns the wrong results), while there's still a way to write the above scenario in a clean, workable way.
Any insight on this issue is mostly welcomed.
-fotos
