Now that Rails 2.3 has been released, I'd like to ask the list to take a look over my proposal ( 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.


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.saved_record? # => true

Of course, this is not what the method does (“dirty?” should be used for this).

Why not “existing_record?”

user =

user.existing_record? # => false

user.existing_record? # => true

Sounds much better.

+1 for existing_record?.

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

+1 for existing_record?

was it this patch here?


This one:

Looks like we have three different patches for the same purpose.
Hackers unite!

My vote is still for "existing_record?" :slight_smile:

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!"


@ ddollar: i cover some use cases in my patch where new_record? won’t suffice.

which i guess i could just repeat here:

  1. Where the find_or_create call is internal to a another wrapper
  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]?


Not only "subject to change" - *is* changed.

That commit made new_record? return false rather than nil in all cases.

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.


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


Lawrence Pit