Will, You actually made a good point there. Removing it would break the
support for reloading `has_one` relationship. Take a look at these SQLs:
student = Student.first
Student Load (0.5ms) SELECT students.* FROM students ORDER BY
students.id ASC LIMIT 1
student.user
User Load
So are you saying project.documents.reload.first would redo the query to find
the associated record, or would do a find(id) to reload the current instance?
On 16/07/2015, at 01:08 , DHH da...@loudthinking.com wrote:
I'd prefer to see us move to a single API, and IMO the trade-offs for
Another idea for the work-around is to add a reload_* association method,
e.g., user.reload_profile.
I'm not sure it's worth adding yet another generated association method (or
even a good idea), but that would make the reload interface consistent with
the build_* and create_* association
I agree that having a single API is nice. However, I feel like it would be
confusing if user want to reload the has_one association, as they have to
reload the original record instead of just passing true.
Consider this scenario:
# User has_one :profile, Profile belongs_to :user
user =
I'd prefer to see us move to a single API, and IMO the trade-offs for
#reload alone fits the bill. There's no contract saying that a singular
object from has_one/belongs_to and a collection like has_many has to behave
the same. In fact, I think it'd be strange to think that it should. A
single
DHH wrote:
I'm content with that work-around. I think it's a very rare situation.
Let's make common things easy and uncommon things possible.
Alright, I'm sold. Let me submit another PR to deprecate that then.
Thank you for your thoughts, everyone.
-Prem
--
You received this
Today a colleague was playing in another branch trying the ruby-saml gem
to play with SAML. When he was back to the master branch all requests
failed for apparently no reason. This is related to this (it was trying
to instantiate some OneLogin class which doesn't exist in master):
