Phusion white papers Phusion overview

Phusion Blog

default_value_for Rails plugin: declaratively define default values for ActiveRecord models

By Hongli Lai on October 3rd, 2008


The default_value_for plugin allows one to define default values for ActiveRecord models in a declarative manner. For example:

class User < ActiveRecord::Base
  default_value_for :name, "(no name)"
  default_value_for :last_seen do

u =       # => "(no name)"
u.last_seen  # => Mon Sep 22 17:28:38 +0200 2008

We at Phusion use it for generating UUIDs for models.

Note: critics might be interested in the “When (not) to use default_value_for?” section. Please read on.


Install with:

./script/plugin install git://

See also the AgileWebDevelopment Plugins entry.

If you like this plugin, then please consider donating and/or recommending us:

Hongli Lai Ninh Bui

The default_value_for method

The default_value_for method is available in all ActiveRecord model classes.

The first argument is the name of the attribute for which a default value should be set. This may either be a Symbol or a String.

The default value itself may either be passed as the second argument:

default_value_for :age, 20

…or it may be passed as the return value of a block:

default_value_for :age do
  if today_is_sunday?

If you pass a value argument, then the default value is static and never changes. However, if you pass a block, then the default value is retrieved by calling the block. This block is called not once, but every time a new record is instantiated and default values need to be filled in.

The latter form is especially useful if your model has a UUID column. One can generate a new, random UUID for every newly instantiated record:

class User < ActiveRecord::Base
  default_value_for :uuid do
end  # => "51d6d6846f1d1b5c9a...."  # => "ede292289e3484cb88...."

Note that record is passed to the block as an argument, in case you need it for whatever reason:

class User < ActiveRecord::Base
  default_value_for :uuid do |x|
    x   # <--- a User object


Instantiation of new record

Upon instantiating a new record, the declared default values are filled into the record. You’ve already seen this in the above examples.

Retrieval of existing record

Upon retrieving an existing record, the declared default values are not filled into the record. Consider the example with the UUID:

user = User.create
user.uuid   # => "529c91b8bbd3e..."

user = User.find(
# UUID remains unchanged because it's retrieved from the database!
user.uuid   # => "529c91b8bbd3e..."


If a certain attribute is being assigned via the model constructor’s mass-assignment argument, that the default value for that attribute will not be filled in:

user = => "hello")
user.uuid   # => "hello"

However, if that attribute is protected by attr_protected or attr_accessible, then it will be filled in:

class User < ActiveRecord::Base
  default_value_for :name, 'Joe'
  attr_protected :name

user = => "Jane")   # => "Joe"


Inheritance works as expected. All default values are inherited by the child

class User < ActiveRecord::Base
  default_value_for :name, 'Joe'

class SuperUser < User
end   # => "Joe"

Attributes that aren’t database columns

default_value_for also works with attributes that aren’t database columns. It works with anything for which there’s an assignment method:

# Suppose that your 'users' table only has a 'name' column.
class User < ActiveRecord::Base
  default_value_for :name, 'Joe'
  default_value_for :age, 20
  default_value_for :registering, true
  attr_accessor :age
  def registering=(value)
    @registering = true

user =
user.age    # => 20
user.instance_variable_get('@registering')    # => true


A conflict can occur if your model class overrides the ‘initialize’ method, because this plugin overrides ‘initialize’ as well to do its job.

class User < ActiveRecord::Base
  def initialize  # <-- this constructor causes problems
    super(:name => 'Name cannot be changed in constructor')

We recommend you to alias chain your initialize method in models where you use default_value_for:

class User < ActiveRecord::Base
  default_value_for :age, 20
  def initialize_with_my_app
    initialize_without_my_app(:name => 'Name cannot be changed in constructor')
  alias_method_chain :initialize, :my_app

Also, stick with the following rules:

  • There is no need to alias_method_chain your initialize method in models that don’t use default_value_for.
  • Make sure that alias_method_chain is called after the last default_value_for occurance.

When (not) to use default_value_for?

You can also specify default values in the database schema. For example, you can specify a default value in a migration as follows:

create_table :users do |t|
  t.string    :username,  :null => false, :default => 'default username'
  t.integer   :age,       :null => false, :default => 20
  t.timestamp :last_seen, :null => false, :default =>

This has the same effect as passing the default value as the second argument to default_value_for:

user =
user.username   # => 'default username'
user.age        # => 20
user.timestamp  # => Mon Sep 22 18:31:47 +0200 2008

It’s recommended that you use this over default_value_for whenever possible.

However, it’s not possible to specify a schema default for serialized columns. With default_value_for, you can:

class User < ActiveRecord::Base
  serialize :color
  default_value_for :color, [255, 0, 0]

And if schema defaults don’t provide the flexibility that you need, then default_value_for is the perfect choice. For example, with default_value_for you could specify a per-environment default:

class User < ActiveRecord::Base
  if RAILS_ENV == "development"
    default_value_for :is_admin, true

Or, as you’ve seen in an earlier example, you can use default_value_for to generate a default random UUID:

class User < ActiveRecord::Base
  default_value_for :uuid do

Or you could use it to generate a timestamp that’s relative to the time at which the record is instantiated:

class User < ActiveRecord::Base
  default_value_for :account_expires_at do
end   # => Mon Sep 22 18:43:42 +0200 2008
sleep(2)   # => Mon Sep 22 18:43:44 +0200 2008

Finally, it’s also possible to specify a default via an association:

# Has columns: 'name' and 'default_price'
class SuperMarket < ActiveRecord::Base
  has_many :products

# Has columns: 'name' and 'price'
class Product < ActiveRecord::Base
  belongs_to :super_market
  default_value_for :price do |product|

super_market = SuperMarket.create(:name => 'Albert Zwijn', :default_price => 100)
soap = super_market.products.create(:name => 'Soap')
soap.price   # => 100

What about before_validate/before_save?

True, before_validate and before_save does what we want if we’re only interested in filling in a default before saving. However, if one wants to be able to access the default value even before saving, then be prepared to write a lot of code. Suppose that we want to be able to access a new record’s UUID, even before it’s saved. We could end up with the following code:

# In the controller
def create
  @user =[:user])
  email_report_to_admin("#{@user.username} with UUID #{@user.uuid} created.")!

# Model
class User < ActiveRecord::Base
  before_save :generate_uuid_if_necessary
  def generate_uuid
    self.uuid = ...
    def generate_uuid_if_necessary
      if uuid.blank?

The need to manually call generate_uuid here is ugly, and one can easily forget to do that. Can we do better? Let’s see:

# Controller
def create
  @user =[:user])
  email_report_to_admin("#{@user.username} with UUID #{@user.uuid} created.")!

# Model
class User < ActiveRecord::Base
  before_save :generate_uuid_if_necessary
  def uuid
    value = read_attribute('uuid')
    if !value
      value = generate_uuid
      write_attribute('uuid', value)
  # We need to override this too, otherwise won't return
  # a default UUID value. I've never tested with User.create() so maybe we
  # need to override even more things.
  def attributes
    def generate_uuid_if_necessary
      uuid  # Reader method automatically generates UUID if it doesn't exist

That’s an awful lot of code. Using default_value_for is easier, don’t you think?

What about other plugins?

I’ve only been able to find 2 similar plugins:

Default Value appears to be unmaintained; its SVN link is broken. This leaves only ActiveRecord Defaults. However, it is semantically dubious, which leaves it wide open for corner cases. For example, it is not clearly specified what ActiveRecord Defaults will do when attributes are protected by attr_protected or attr_accessible. It is also not clearly specified what one is supposed to do if one needs a custom initialize method in the model.

I’ve taken my time to thoroughly document default_value_for’s behavior.


I’ve wanted such functionality for a while now and it baffled me that ActiveRecord doesn’t provide a clean way for me to specify default values. After reading, it became clear that someone needs to write a plugin. This is the result.

Thanks to Pratik Naik for providing the initial code snippet on which this plugin is based on:

If you like this plugin, then please consider donating and/or recommending us:

Hongli Lai Ninh Bui
  • This is a nice way of handling things, but instead of overwriting ActiveRecord::Base#initialize, have you thought about modifying ActiveRecord::Base#after_initialize?

    > However, it’s not possible to specify a schema default for serialized columns.

    This isn’t entirely true. For BLOB/TEXT (text), you can’t define defaults. For VARCHAR (string), you can get away with serialization by feeding in YAML: `t.string :color, [255, 0, 0].to_yaml.chop`.

    (String#chop is needed to get rid of the newline character.)

  • Yeah, there have been discussions about after_initialize. But it makes too many corner case problems possible.

  • Would be nice to have this in AR by default. Please consider proposing a patch for Rails. Also, isn’t it time to recommend me back on wwr? 😉

  • Yes I agree, this should be in core … please consider notifying the proper authorities! 🙂

  • +1 for core addition. Great work.

  • I’d vote for not including it in ActiveRecord, but that’s only because we already use something with exactly the same name and syntax at Moneyspyder 🙂 (Only joking, actually, it would be excellent to have in there.)

    Our version just hooks before_validate — suits us in most situations, you can always validate the record and get the default value out (by calling valid? on it) if you really need it, but it doesn’t come up that often. We actually use default_value_for in most places — putting the defaults in the DB causes too many issues (unless things have improved since Rails 1.1). Also is easier to debug.

    The default_price thing is nice, I might take that idea 🙂 — might be harder to make in a before_validation hook though.

  • Pingback: Double Shot #306 « A Fresh Cup()

  • Pingback: Nome do Jogo » Blog Archive » Rails Podcast Brasil - Episódio 33()

  • Pingback: เร็วส์ หกสิบหก » นั่งเทียนเขียนข่าว#14()

  • When getting the default value via an association, like in your example, the ‘create’ method works fine, but the ‘build’ method does not fill the attribute with the desired value, leaving it nil, like so:

    super_market = SuperMarket.create(:name => ‘Albert Zwijn’, :default_price => 100)
    soap = => ‘Soap’)
    soap.price # => nil

  • Oops, submitted too early… 🙂 Anyway, the current workaround is to pass the attribute via the params for the build method (which should not be necessary, since this is a build via the association), like this:

    super_market = SuperMarket.create(:name => ‘Albert Zwijn’, :default_price => 100)
    soap = => super_market, :name => ‘Soap’)
    soap.price # => 100

  • Those aren’t UUIDs, those are just hex digests of big random numbers. Take a look at RFC 4122.

    UUIDs look like this: 343e50b4-ba44-11dd-beb2-001ec2186a45

    And they’re not just a random number. I wrote a Ruby library awhile back for generating real UUIDs, and it’s probably worth using, since it really does give you true uniqueness. Plus it runs on Ruby 1.8.x, 1.9.x, and JRuby.

    Your code above would become:

    require "uuidtools"
    class User "ee0ec316-ba44-11dd-beb2-001ec2186a45" # => "ee79dc32-ba44-11dd-beb2-001ec2186a45"

  • Matt Powell

    I don’t know whether this is a real bug or just a caveat, but if you call

    default_value_for :foo, {}

    …then the same hash is shared between instances. Perhaps a call to duping the default would work: in the mean time I am using the block form of default_value_for.

  • soren


    I use default_value in my model for students to set some inheritance:
    class Student “3c03f9d9352d163861e6ba703f1e633a”, “action”=>”new”, “_method”=>”get”, “adapter”=>”_list_inline_adapter”, “controller”=>”student”}

    SystemStackError (stack level too deep):
    vendor/plugins/default_value_for/init.rb:38:in `call’
    vendor/plugins/default_value_for/init.rb:38:in `evaluate’
    vendor/plugins/default_value_for/init.rb:81:in `initialize’
    vendor/plugins/default_value_for/init.rb:79:in `initialize’
    vendor/plugins/default_value_for/init.rb:71:in `initialize’

    Rendered rescues/_trace (27.2ms)
    Rendered rescues/_request_and_response (1.2ms)

    Mongrel Bootup in Production mode:
    => Booting Mongrel
    => Rails 2.3.2 application starting on
    /rails/formdir-dev/app/models/student.rb:7: warning: Object#id will be deprecated; use Object#object_id
    /usr/lib64/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:443:in `load_missing_constant’: uninitialized constant Logging (NameError)
    from /usr/lib64/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:80:in `const_missing’
    from /usr/lib64/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/dependencies.rb:92:in `const_missing’
    from /usr/lib64/ruby/gems/1.8/gems/logging-1.1.2/lib/logging.rb:479
    from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:32
    /rails/formdir-dev/app/models/student.rb:8: undefined method `last_name’ for nil:NilClass (NoMethodError)
    from /rails/formdir-dev/vendor/plugins/default_value_for/init.rb:38:in `call’
    from /rails/formdir-dev/vendor/plugins/default_value_for/init.rb:38:in `evaluate’
    from /rails/formdir-dev/vendor/plugins/default_value_for/init.rb:81:in `initialize’
    from /usr/lib64/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/ordered_hash.rb:69:in `each’
    from /usr/lib64/ruby/gems/1.8/gems/activesupport-2.3.2/lib/active_support/ordered_hash.rb:69:in `each’
    from /rails/formdir-dev/vendor/plugins/default_value_for/init.rb:79:in `initialize’
    from /usr/lib64/ruby/gems/1.8/gems/activerecord-2.3.2/lib/active_record/base.rb:2441:in `initialize_without_defaults’
    from /rails/formdir-dev/vendor/plugins/default_value_for/init.rb:71:in `initialize’
    … 22 levels…
    from /usr/lib64/ruby/gems/1.8/gems/rails-2.3.2/lib/commands/server.rb:84
    from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require’
    from /usr/lib64/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require’
    from script/server:3

  • soren

    Re last post

    Sorry the beginning did not come out correctly:

    It should have shown this:

    I use default_value in my model for students to set some inheritance:
    class Student < ActiveRecord::Base

    belongs_to :user
    belongs_to :klass

    # Create programatic default values for each element in the database
    default_value_for :user_id do end
    default_value_for :last_name do current_user.last_name end
    default_value_for :address do current_user.address end
    default_value_for :city do end
    default_value_for :zip do end
    default_value_for :home_phone do current_user.home_phone end

    default_value_for has worked fine for me under Rails 2.2.2 in Production and Development, but it fails under Rails 2.3

    In Development mode it fails when the student model (per above) is used. Error message is:
    (as shown in previous post)

    In Production mode it prevents Mongrel from starting up. The Mongrel bootup log is shown in the previous post.

    Sorry for the edit mixup

  • reddyonrails

    Thanks for article. I like uuid example….

    ++ for core addition.

  • Emma

    Does it works with nested attributes?

    I’m having problem with this:

    class Person …)

    the problem is that p.category now returns the default value.

  • Emma

    Sorry the last post came out wrong.

    Does it works with nested attributes?

    I’m having problem with this:

    class Person ...)

    the problem is that p.category now returns the default value.

  • Doug

    It doesn’t look like it but I’m not sure if this gets me a workaround for this

    class Student < ActiveRecord::Base
    has_many :klasses

    def after_initialize => id, :status => “registered”)

    @student =
    @student.klasses # <– klass id: nil, student_id: 1, status: registered

    thus automatically building the klasses association right when a new student is created. Unfortunately after_initialize is also called on find which causes problems. Thus the need for a workaround.

    Ya I know its a strange example. Sorry again. No preview.

  • Tom Maeckelberghe

    You should keep in mind that you have to be aware of the possible dangers of the plugin. You should know about the inner workings of this plugin before working with it.

    How the plugin works

    1) remember all the attributes that are supplied to new
    ex. => “bla”, :price => “€5”)
    default_value_for will remember that the name and the price are set.

    2) the new product attributes will be overwritten with the default values except for price and name

    problem case:

    class Product
    default_values {:price => “5”, :currency => “$”}
    def price= price_and_currency
    self.price = separate_price_form_price_and_currency(price_and_currency)
    self.currency = separate_currency_form_price_and_currency(price_and_currency)
    end => “bla”, :price => “€6”)
    attributes are correctly set and not touched by the plugin
    1) :name => “bla”, :price => “€6”, :currency => “€”
    Then the plugin overwrites attributes with default values except for :price
    BUT it will not check on custom setters which alter other attributes
    2) :name => “bla”, :price => “€6”, currency => “$”
    Our ‘€’ got overwritten by the default value of ‘$’