order(*args) public

Allows to specify an order attribute:

=> SELECT "users".* FROM "users" ORDER BY name

User.order('name DESC')
=> SELECT "users".* FROM "users" ORDER BY name DESC

User.order('name DESC, email')
=> SELECT "users".* FROM "users" ORDER BY name DESC, email

=> SELECT "users".* FROM "users" ORDER BY "users"."name" ASC

User.order(email: :desc)
=> SELECT "users".* FROM "users" ORDER BY "users"."email" DESC

User.order(:name, email: :desc)
=> SELECT "users".* FROM "users" ORDER BY "users"."name" ASC, "users"."email" DESC
Show source
Register or log in to add new notes.
March 27, 2012
5 thanks


If you want to override previously set order (even through default_scope), use reorder() instead.


User.order('id ASC').reorder('name DESC')

would ignore ordering by id completely

October 28, 2014
2 thanks

Ordering on associations

For ordering on the attribute of an associated model you have to include it:

October 30, 2014 - (v3.0.0 - v3.2.13)
1 thank

Order with hash parameters only in ActiveRecord >= 4.0

If you use order with hash parameters on AR3 versions it wont work.

January 12, 2014
0 thanks

using hash as order

order can be specified as a hash, e.g.:

order(id: :desc)

This will prevent “ambiguous column” errors when the order is used with joins or includes.

February 12, 2015
0 thanks


adding to stevo’s comment that reorder is also usefull when you have default scope in your model. eg: default_scope -> { order(created_at: :desc) }

October 5, 2015 - (>= v3.2.1)
0 thanks

arel_table order by

More objected way how to achieve ORDOR BY .… DESC is like this :

class User < ActiveRecord::Base
  has_many :status_changes

  def latest_status_change

class StatusChange < ActiverRecord::Base
  belongs_to :user

resulting in:

SELECT "status_changes".* FROM "status_changes" WHERE "status_changes"."user_id" = 1 ORDER BY "status_changes"."created_at" DESC


  • you are strictly bound to Modelclass name => renaming table in model will not break the sql code (of if it will, it will explicitly break the syntax on Ruby level, not DB level)

  • you still have the benefit of explicitly saying what table.column the order should be

  • easier to re-factor parts to Query Objects