I am trying to set some default values for an object using after_initialize
. The problem I am having is that I would like this to be called no matter how the object is created.
My class:
class Foo < ActiveRecord::Base
serialize :data
after_initialize :init
def init
self.data ||= {}
self.bar ||= "bar"
self.baz ||= "baz"
end
end
Everything works fine if I call Foo.new
, Foo.new(:bar => "things")
and Foo.create(:baz => 'stuff')
. However when I use a block with create
the after_initialize
callback doesn't get run.
obj = Foo.create do |f|
f.bar = "words"
f.data = { :attr_1 => 1, :attr_2 => 2 }
end
This just yields obj.baz
=> nil
instead of "baz"
with the other attributes set correctly.
Am I missing something with the way callbacks are executed, with the differences with calling create with a block and without or are default values getting clobbered by the block?
UPDATE
Found the issue.
It turns out that calling create
with block and without are subtly different. When you call create
without a block and just pass in a hash of parameters, for all intents and purposes you are calling Foo.new({<hash of argument>}).save
, and the after_initialize
callback gets executed right before the save like you would expect.
When you call create
with a block something a little different happens. The order of events is Foo.new
is called with whatever arguments you pass in, then after_initialize
gets called, then the block gets run. So if you are using the block (as I was) interchangeably with the hash parameters just to make things a little bit more readable you could get bit because your after_initialize
is run before all of the parameters you intend to set are actually set.
I got bit because I was doing some extra work in the after_initialize
setting some extra required attributes based on the value of what was getting passed. Since nothing was actually set when after_initialize
got called, nothing got set correctly and my validations failed.
I ended up having to make to calls to init
. Once on after_initialize
and once on before_validation
. Not the cleanest, but it solved the issue.
Thanks go to Brandon for pointing me in the right direction.
I'm unable to reproduce this. I happen to have an application handy with the following (simplified) class:
class Service < ActiveRecord::Base
serialize :data, Hash
after_initialize :create_default_data
attr_accessible :data, :token
protected
def create_default_data
self.data ||= Hash.new
end
end
Here's an IRB session:
ruby-1.9.2-p136 :001 > obj = Service.create do |s|
ruby-1.9.2-p136 :002 > s.token = "abc"
ruby-1.9.2-p136 :003?> end
=> #<Service id: 22, user_id: nil, type: nil, data: {}, created_at: "2011-03-05 04:18:00", updated_at: "2011-03-05 04:18:00", token: "abc">
ruby-1.9.2-p136 :004 > obj.data
=> {}
As you can see, data
as initialized in the after_initialize
method to an empty hash. The Rails code indicates this makes sense as well; in create
:
def create(attributes = nil, &block)
if attributes.is_a?(Array)
attributes.collect { |attr| create(attr, &block) }
else
object = new(attributes)
yield(object) if block_given?
object.save
object
end
end
So create
calls new
and assigns the value to object
before it yield
s. Here's the relevant part in new
:
def initialize(attributes = nil)
# truncated for space
result = yield self if block_given?
run_callbacks :initialize
result
end
As you can see, new
unconditionally calls the initialize
callbacks before it returns, and thus before create
even yields to the block you pass. By the time your block gets the object, the after_initialize
method has already executed.
Double check that (1) your version of Rails is up to date (3.0.5 as of now I believe) and that (2) nothing is setting baz
without you realizing it.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With