Now that Rails 2.3 has been released, I''d like to ask the list to take a look over my proposal (http://rails.lighthouseapp.com/projects/8994/tickets/2228-activerecordbasesaved ) to add an ActiveRecord::Base#saved_record? method. It is an extremely simple patch, which is just the opposite of new_record? It is along the same lines as the invalid? method. It adds a more readable method for the opposite functionality. Thanks for your time. Cheers --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Mar 18, 2009 at 13:12, Olly Legg <ollylegg@gmail.com> wrote:> > It is along the same lines as the invalid? method. It adds a more > readable method for the opposite functionality.The name "saved_record?" might be misleading -- developers might think that this method returns false before the "save" method was called and true after the call: user.saved_record? # => false user.save user.saved_record? # => true Of course, this is not what the method does ("dirty?" should be used for this). Why not "existing_record?" user = User.new user.existing_record? # => false user.save user.existing_record? # => true Sounds much better. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
+1 for existing_record?. I think I already saw a patch about "existing_record?" in lighthouse. On Mar 18, 4:04 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:> On Wed, Mar 18, 2009 at 13:12, Olly Legg <ollyl...@gmail.com> wrote: > > > It is along the same lines as the invalid? method. It adds a more > > readable method for the opposite functionality. > > The name "saved_record?" might be misleading -- developers might think that > this method returns false before the "save" method was called and true after > the call: > > user.saved_record? # => false > user.save > user.saved_record? # => true > > Of course, this is not what the method does ("dirty?" should be used for > this). > > Why not "existing_record?" > > user = User.new > user.existing_record? # => false > user.save > user.existing_record? # => true > > Sounds much better.--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
+1 for existing_record? On Wed, Mar 18, 2009 at 11:04 AM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> On Wed, Mar 18, 2009 at 13:12, Olly Legg <ollylegg@gmail.com> wrote: > >> >> It is along the same lines as the invalid? method. It adds a more >> readable method for the opposite functionality. > > > The name "saved_record?" might be misleading -- developers might think that > this method returns false before the "save" method was called and true after > the call: > > user.saved_record? # => false > user.save > user.saved_record? # => true > > Of course, this is not what the method does ("dirty?" should be used for > this). > > Why not "existing_record?" > > user = User.new > user.existing_record? # => false > user.save > user.existing_record? # => true > > Sounds much better. > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
was it this patch here? http://rails.lighthouseapp.com/projects/8994/tickets/2089-add-arbasejust_created-to-differenciate-records RSL On Wed, Mar 18, 2009 at 11:11 AM, José Valim <jose.valim@gmail.com> wrote:> > +1 for existing_record?. > > I think I already saw a patch about "existing_record?" in lighthouse. > > On Mar 18, 4:04 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote: > > On Wed, Mar 18, 2009 at 13:12, Olly Legg <ollyl...@gmail.com> wrote: > > > > > It is along the same lines as the invalid? method. It adds a more > > > readable method for the opposite functionality. > > > > The name "saved_record?" might be misleading -- developers might think > that > > this method returns false before the "save" method was called and true > after > > the call: > > > > user.saved_record? # => false > > user.save > > user.saved_record? # => true > > > > Of course, this is not what the method does ("dirty?" should be used for > > this). > > > > Why not "existing_record?" > > > > user = User.new > > user.existing_record? # => false > > user.save > > user.existing_record? # => true > > > > Sounds much better. > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
This one: http://rails.lighthouseapp.com/projects/8994/tickets/2228-activerecordbasesaved Looks like we have three different patches for the same purpose. Hackers unite! My vote is still for "existing_record?" :) On Mar 18, 4:16 pm, RSL <sco...@gmail.com> wrote:> was it this patch here? > > http://rails.lighthouseapp.com/projects/8994/tickets/2089-add-arbasej... > > RSL > > On Wed, Mar 18, 2009 at 11:11 AM, José Valim <jose.va...@gmail.com> wrote: > > > +1 for existing_record?. > > > I think I already saw a patch about "existing_record?" in lighthouse. > > > On Mar 18, 4:04 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote: > > > On Wed, Mar 18, 2009 at 13:12, Olly Legg <ollyl...@gmail.com> wrote: > > > > > It is along the same lines as the invalid? method. It adds a more > > > > readable method for the opposite functionality. > > > > The name "saved_record?" might be misleading -- developers might think > > that > > > this method returns false before the "save" method was called and true > > after > > > the call: > > > > user.saved_record? # => false > > > user.save > > > user.saved_record? # => true > > > > Of course, this is not what the method does ("dirty?" should be used for > > > this). > > > > Why not "existing_record?" > > > > user = User.new > > > user.existing_record? # => false > > > user.save > > > user.existing_record? # => true > > > > Sounds much better.--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Why not just use unless object.new_record? It seems like any of the saved/existing/etc_record? have potentially non-obvious meanings. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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!" -Rob --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
@ ddollar: i cover some use cases in my patch where new_record? won''t suffice. http://rails.lighthouseapp.com/projects/8994/tickets/2089-add-arbasejust_created-to-differenciate-records#ticket-2089-3 which i guess i could just repeat here: 1. Where the find_or_create call is internal to a another wrapper method. 2. Where you need to operate on a saved record [most likely needing the id attribute]. @jose three tickets? i just see mine [from last month] and this one [from today]. and it looks like my implementation does a little more than what this one does which seems to simply wrap !new_record? with saved_record? [unless i''m missing something]? rsl On Wed, Mar 18, 2009 at 1:58 PM, David Dollar <ddollar@gmail.com> wrote:> > Why not just use unless object.new_record? > > It seems like any of the saved/existing/etc_record? have potentially > non-obvious meanings. > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Matt: you might not need to run said code for every save. in my use case, i only had to use it once out of all the saves i do for the class in my entire app. RSL On Wed, Mar 18, 2009 at 3:01 PM, Matt Jones <al2o3cr@gmail.com> wrote:> > > 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
while we''re at it, I propose to alias :new_record? as :new? and :existing_record? as :exists? Cheers, Lawrence Pit> This one: > > http://rails.lighthouseapp.com/projects/8994/tickets/2228-activerecordbasesaved > > Looks like we have three different patches for the same purpose. > Hackers unite! > > My vote is still for "existing_record?" :) > > On Mar 18, 4:16 pm, RSL <sco...@gmail.com> wrote: > >> was it this patch here? >> >> http://rails.lighthouseapp.com/projects/8994/tickets/2089-add-arbasej... >> >> RSL >> >> On Wed, Mar 18, 2009 at 11:11 AM, José Valim <jose.va...@gmail.com> wrote: >> >> >>> +1 for existing_record?. >>> >>> I think I already saw a patch about "existing_record?" in lighthouse. >>> >>> On Mar 18, 4:04 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote: >>> >>>> On Wed, Mar 18, 2009 at 13:12, Olly Legg <ollyl...@gmail.com> wrote: >>>> >>>>> It is along the same lines as the invalid? method. It adds a more >>>>> readable method for the opposite functionality. >>>>> >>>> The name "saved_record?" might be misleading -- developers might think >>>> >>> that >>> >>>> this method returns false before the "save" method was called and true >>>> >>> after >>> >>>> the call: >>>> >>>> user.saved_record? # => false >>>> user.save >>>> user.saved_record? # => true >>>> >>>> Of course, this is not what the method does ("dirty?" should be used for >>>> this). >>>> >>>> Why not "existing_record?" >>>> >>>> user = User.new >>>> user.existing_record? # => false >>>> user.save >>>> user.existing_record? # => true >>>> >>>> Sounds much better. >>>> > > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---