The Order of Rails Validation Filters

Here are the available Rails validation filters:

before_validation_on_update
before_validation_on_create
validate
validate_on_update
validate_on_create
after_validation
after_validation_on_update
after_validation_on_create
before_save
before_update
before_create
after_update
after_create
after_save



These filters are callbacks that are invoked automatically.

The difference between update and create is really with respect to the database. If the record you are saving is a new record in the db, then it means you are creating. If the item already exists but you are making a change, then it means you are updating. In other words, it does not matter, whether you called obj.save or obj.create, before_update filter will be invoked. The same is true for obj.save vs. obj.update_attributes. So no matter what Active record method you invoke the filter is decided based on the database record.

How about before_save, before_after_save? They will always be invoked whether you are creating or updating.

In the light of this information, the order of these filter is as follows:

  1. before_validation
  2. before_validation_on_update or before_validation_on_create
  3. validate
  4. validate_on_update or validate_on_create
  5. after_validation
  6. after_validation_on_update or after_validation_on_create
  7. before_save
  8. before_update or before_create
  9. after_update or after_create
  10. after_save

Note that before_save is invoked before before_update and before_create, while after_save is invoked after after_update and after_create.

Comments

deezzer said…
This comment has been removed by the author.
April 5, 2009 at 1:10 AM
deezzer said…
Great insight. I was thinking before_save would be invoked if you created a new record using @object.save and before_create would be if you used Object.create()

I appreciate that Rails makes this indifferent. I mean, is it realistic that coders are consistent with the methods they use to create/save new objects? No way!

Thanks for clarifying.
April 5, 2009 at 1:11 AM
Anonymous said…
This comment has been removed by the author.
May 17, 2011 at 9:19 AM
Post a Comment

Popular posts from this blog

Accessing Resources in Java, use of getResource method of Class and ClassLoader, How to access test data in unit tests

Given that: TestABC.java is located at: test/x/y/z/TestABC.java testdata.txt is located at: resources/x/y/z/TestABC/testdata.txt classpath includes resources folder We are trying to read the testdata.txt from TestABC.java. We need a location independent way to point to these files. Therefore, we would like to use getResource() method of a Class or ClassLoader. Here are the correct ways: 1: this.getClass().getClassLoader().getResource("x/y/z/TestABC/testdata.txt"); 2: this.getClass().getResource("/x/y/z/TestABC/testdata.txt")); 3: this.getClass().getResource("TestABC/testdata.txt")); Explanation: 1: works because ClassLoader takes the path as it is (no manipulation) and search in the classpath folders. In this case, it will go to the resources folder and it will find the testdata.txt file in the given path. 2: works because Class.getResource takes the "absolute" path, removes its starting / and t
Read more

Comparison of equality operators in Ruby: == vs. equal? vs. eql? vs. ===

Here is a short explanation of when these predicates are true (From http://www.wellho.net/mouth/985_Equality-in-Ruby-eql-and-equal-.html) The == comparison checks whether two values are equal eql? checks if two values are equal and of the same type equal? checks if two things are one and the same object. How do I remember which is which ... The longer the operator, the more restrictive the test it performs Let's understand the differences with some examples. Each "abc" below is a different object. Therefore, equal? is false. irb(main):065:0> "abc".object_id => 24173330 irb(main):066:0> "abc".object_id => 24165760 irb(main):067:0> "abc" == "abc" => true irb(main):068:0> "abc".eql? "abc" => true irb(main):069:0> "abc".equal? "abc" => false As you might expect, there is a single instance of 1. Therefore, all comparisons are true. irb(main):094:0> 1.class =>
Read more