On Mar 18, 2009, at 2:27 PM, Rob Biedenharn wrote:
>
> On Mar 18, 2009, at 1:58 PM, David Dollar wrote:
>> Why not just use unless object.new_record?
>>
>> It seems like any of the saved/existing/etc_record? have potentially
>> non-obvious meanings.
>
> Because object=Model.find_or_create...() will result in
> object.new_record? never being true. In my code, I have occasionally
> done:
>
> if object.new_record?.nil? # new_record? is false on create, but
> nil on find
>
> Which is depending on a kind of behavior that is clearly subject to
> change. I could have been a bit more invasive with
> object.instance_variable_get("@new_record_before_save"), but.. "Ew!"
Not only "subject to change" - *is* changed.
http://github.com/rails/rails/commit/6e98adfc8e19a39fa45d4acd94145d318d151964
That commit made new_record? return false rather than nil in all cases.
---
Back to the topic at hand, though, I'm still not seeing when this is
useful. If you're creating an object with find_or_create_by but it's
not really valid, it seems likely that something's wrong with the
design...
The cases in the ticket don't help - the first doesn't explain why,
and the second doesn't make any sense. Records created by
find_or_create *have* ID values... What can you do with just_created?
that can't/shouldn't be done in an after_create callback?
--Matt Jones
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
