Thanks for the response Michael and the clarification. I also noted the following patch which seems related to the functionality you describe.
http://dev.rubyonrails.org/ticket/7368 However, I would like to suggest the following three points and get your feedback: 1) This is poorly documented. I checked out: http://api.rubyonrails.org/classes/ActiveRecord/Base.html and found the section on dynamic finders somewhat vague on the topic. There does seem to be one example that covers what you just described (The last in the dynamic finders topic) but I think there is a lot of room for improvement, especially since the dynamic finders are not documented in the API docs with rdocs dedicated to each find_or_initialize_by or find_or_create_by method. In other words, no method signature is easily available since these are method_missing dynamic methods. How can we improve this? 2) Understanding what the current functionality is, and accepting that, don't you think that the find_or_create|initialize_by methods *should* accept conditions for the find operation to be consistent with the normal find_by methods? So in that case you could make a call like: @user = User.find_or_initialize_by_email(:email => '[EMAIL PROTECTED]', :name => 'Foo Bar', :conditions => {:state => 'passive'}) Which would do: - Find a user with the email '[EMAIL PROTECTED]' WHERE state='passive' - set the @user.name attribute to 'Foo Bar' This approach would seem to be more consistent with the other non- instantiating/creating dynamic finders. Is there a reason this should not be the case? 3) If the approach in (2) is not appropriate for some reason, shouldn't find_or_create|initialize_by raise an exception/warning if passed :conditions instead of silently swallowing them (which gives the user the false impression that they are actually being considered as part of the find since that is the behavior they are used to with other dynamic finders). This is what bit me, as I assumed based on my read of the docs that they would take conditions, but only later when I watched the SQL being generated did I see the error of my ways. This was a silent bug in my code which I had to implement using standard finders and an if statement to determine whether to create a new object or update the attributes of an existing one. I will be willing to help with these, although my method_missing 'fu' is weak... so I am hoping that someone else will agree and patch it which I will surely +1 on. :-) I can help with a documentation patch if useful. Thanks, Glenn On Feb 9, 12:28 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > On Feb 8, 2008 2:00 PM, Glenn Rempe <[EMAIL PROTECTED]> wrote: > > > > > > > Hello, I posted this on the rails talk group but received no > > response. Perhaps someone on this list could weigh in on whether this > > is expected/desired behavior or a bug that I should file and develop > > failing tests for > > (I doubt I have the active record method_missing fu to actually patch > > it). > > > Test Scenario: > > I would like to find or initialize a new user and base the find on the > > users email address, however the user found has to also match one of > > two possible 'state' values (passive || pending_singup). While trying > > to implement this I discovered that the find_or_(initialize| > > create)_by_* dynamic finders totally and silently ignore any > > conditions passed. > > > Bug? > > Not really. Because the second argument to those dynamic initializers > is an attributes hash to be added to the newly created object, not > arguments for find. So it's treating them as if you want to call > > @user.conditions= {:state => 'passive'} > > if it doesn't find a user with that email address. > > -- > Cheers > > Koz --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
