ActiveRecord::Base#saved_record?

rubyonrails-core
1

Now that Rails 2.3 has been released, I'd like to ask the list to take a look over my proposal (#2228 ActiveRecord::Base#saved? - Ruby on Rails - rails) 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

2

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.

3

+1 for existing_record?.

I think I already saw a patch about "existing_record?" in lighthouse.

4

+1 for existing_record?

5

was it this patch here?

http://rails.lighthouseapp.com/projects/8994/tickets/2089-add-arbasejust_created-to-differenciate-records

RSL

6

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?" :slight_smile:

7

Why not just use unless object.new_record?

It seems like any of the saved/existing/etc_record? have potentially non-obvious meanings.

8

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

9

@ 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

10

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.

11

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

12

while we’re at it, I propose to alias :new_record? as :new? and :existing_record? as :exists?

Cheers,

Lawrence Pit