I have a database column named ‘status’ in my ‘orders’ table. When an
order placed, I’d like to initialize this column value to be ‘in
progress’. Is it best to do this in:
A) the database migration
B) the database itself
C) in before_create
My personal preference is to do it in the before_create. This way it
is very evident to me when I look at the model as to what the value is
going to be initialized to. Are there performance issues with doing
this?
Jody Baty
Lead Developer
my Curriculum Analysis Tools (www.mycatshq.com)
i am using Oracle for back-end storage, so all my default values for
columns are in sql scripts, which is separate folder,
and i don’t think introduction of default value in any of the 3 places
you mentioned will lead to performance problem.
(Worst case: if it affects also it should be very very negligible, but
i don’t have benchmark results, personally i feel, it will not)
I have a database column named ‘status’ in my ‘orders’ table. When an
order placed, I’d like to initialize this column value to be ‘in
progress’. Is it best to do this in:
A) the database migration
B) the database itself
C) in before_create
My personal preference is to do it in the before_create. This way it
is very evident to me when I look at the model as to what the value is
going to be initialized to. Are there performance issues with doing
this?
I don’t think there are performance issues to worry about. The
before_create callback imposes a bit of overhead, but it’s nothing to
worry about. I’d go with the before_create approach, since I like to
keep as much of my biz logic in Ruby as I can. Makes it easier to tell
what’s going on, it’s more portable, and I’m better at Ruby than SQL.
Note that if you are using before_create callback and you make an object
with #new instead of #create, you can have an object floating around
that hasn’t had that attribute initialized as you might expect. For
those situtations, I often do lazy initialization on accessors:
def foo
self.attributes[:foo] ||= “default value”
end