Veerasundaravel's Ruby on Rails Weblog

November 26, 2014

Rails find_each method with order option

Filed under: Rails3, Ruby, Ruby On Rails — Tags: , , , , , , , — Veerasundaravel @ 9:36 pm
Rails find_each or find_in_batches methods are looping through a collection of records from the database.
This batch processing methods allow us to work with the records in batches, thereby greatly reducing memory consumption.
Person.find_each(:conditions => "age > 21") do |person|
But major drawback with these methods is  - ordering/sorting the records by primary key id, hence we cannot specify our own order_by.
order_by(:created_at).find_each == FAIL!!!
class ActiveRecord::Base
  # normal find_each does not use given order but uses id asc
  def self.find_each_with_order(options={})
    raise "offset is not yet supported" if options[:offset]

    page = 1
    limit = options[:limit] || 1000

    loop do
      offset = (page-1) * limit
      batch = find(:all, options.merge(:limit=>limit, :offset=>offset))
      page += 1

      batch.each{|x| yield x }

      break if batch.size < limit

July 2, 2014

Rails – Force update ActiveRecord updated_at column

Filed under: Ruby On Rails — Tags: , , , , , , — Veerasundaravel @ 12:11 am

When we usually modify any specific column/field in our model, Active-record will check whether the corresponding value is new or not.

If it is new then only it will create a DB query and update that value with current timestamp in updated_at column, if there is no change in existing value means it will only fire commit query only. There wont be any change in updated_at column.

So if we want modify the timestamp of updated_at field without updating any field means, we can follow any of below two methods:

Method 1:
user.update_attributes(:name => “same old name”, :updated_at =>

Method 2:

Both of above two methods will modify updated_at value with current timestamps even if there is any change in other fields or not.


July 25, 2012

Rspec Shoulda-Matcher made Unit testing as easier one

Filed under: Rails3, Ruby, Ruby On Rails, Testing, Unit Test — Tags: , , , , , , — Veerasundaravel @ 12:37 am

Shoulda matcher is a library that enables to write better and more understandable tests for Rails application. It is Test::Unit- and RSpec-compatible one-liners that test common Rails functionality.

Here few very easier example of shoulda-matchers for Unit Testing.

Test model fields:

it {should have_db_column(:login)}
it {should have_db_column(:salary).of_type(:decimal).with_options(:precision =&gt; 10, :scale =&gt; 2) }
it { should_not have_db_column(:admin).of_type(:boolean) }

Test db indexes:

it { should have_db_index(:age) }
it { should have_db_index([:commentable_type, :commentable_id]) }
it { should have_db_index(:ssn).unique(true) }

Test validations:

it { should validate_uniqueness_of(:title) }
it { should validate_presence_of(:body).with_message(/Enter the message/) }
it { should validate_presence_of(:title) }
it { should validate_numericality_of(:user_id) }
it { should validate_uniqueness_of(:title) }
it { should_not allow_value("blah").for(:email) }
it { should allow_value("").for(:email) }
it { should ensure_inclusion_of(:age).in_range(1..100) }
it { should_not allow_mass_assignment_of(:password) }

Test associations:

it { should belong_to(:parent) }
it { should have_one(:car)
it { should have_many(:friends) }
it { should have_many(:enemies).through(:friends) }


Further reading:

Shoulda-Matcher home page –
Shoulda-context home page –
rspec_shoulda cheat sheet –


Older Posts »

%d bloggers like this: