# Handling default values in models

**URL:** <https://www.ruby-forum.com/t/handling-default-values-in-models/131286>\
**Category:** Rails\
**Created:** [March 7, 2008, 5:13pm UTC](https://www.ruby-forum.com/t/handling-default-values-in-models/131286 "2008-03-07T17:13:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![byrnejb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/d2c977/32.png) [@byrnejb](https://www.ruby-forum.com/u/byrnejb)\
**Post date:** [March 7, 2008, 5:13pm UTC](https://www.ruby-forum.com/t/handling-default-values-in-models/131286/1 "2008-03-07T17:13:28Z")

</div>

I have been searching for articles and code relating to setting default  
values inside the model and I have found several different approaches to  
this issue. I am therefore inquiring if the community has formed any  
consensus on the “best practice” in this regard?

There are frequent occasions when a sensible default value is  
determinable from the context and to save redundant user input I would  
like to provide these values automatically. Further, I happen to  
subscribe to the not null school of database design, the only (rare)  
exception being the case of a presently unknown but applicable value.  
This means that that these fields require some input or the DBMS  
constraints are going trip.

One interesting item that I ran across is the active\_record\_defaults  
plugin by a fellow from NZ. Does anyone have any comments on this  
plugin or can offer any alternatives?

Regards,

---

<div class="post-metadata">

**Author:** ![byrnejb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/d2c977/32.png) [@byrnejb](https://www.ruby-forum.com/u/byrnejb)\
**Post date:** [March 7, 2008, 5:46pm UTC](https://www.ruby-forum.com/t/handling-default-values-in-models/131286/2 "2008-03-07T17:46:45Z")

</div>

You can do it by passing default parameters to the model on new. You  
can push this down from the controller to the model as a method if you  
want, e.g.

@user=User.new\_with\_defaults

The view will then pick up the defaults.

or if you want to make sure that the defaults are in place in all  
places where a new object might be used then stick the code in  
‘after\_initialize’.

If you need to do some calcs then there is always  
‘before\_validation\_on\_create’ or just ‘before\_create’. If you need to  
do the calcs all the time then ‘before\_save’.

It depends what you’re trying to achieve.

What you don’t do is rely upon defaults in the database. For me the  
default calculations have to be in the model.

On Mar 7, 4:13 pm, James B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![byrnejb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/d2c977/32.png) [@byrnejb](https://www.ruby-forum.com/u/byrnejb)\
**Post date:** [March 7, 2008, 7:02pm UTC](https://www.ruby-forum.com/t/handling-default-values-in-models/131286/3 "2008-03-07T19:02:01Z")

</div>

Neil W. wrote:

> It depends what you’re trying to achieve.

For now, I wish to provide a simple, explicit, and model-centric means  
of specifying default values for certain table attributes. Since I  
posted above I have installed the active\_record\_defaults plugin and this  
seems to provide most of what I desired.  
For example:

Class MyTable \< ActiveRecord::Base

belongs\_to :my\_other\_table

# code dependent on active\_record\_defaults plugin

default :effective\_from =\> Time.now  
defaults :my\_attribute =\> “unknown”, :my\_int\_attribute =\> 21

validates\_presence\_of :another\_attribute

> What you don’t do is rely upon defaults in the database. For me the  
> default calculations have to be in the model.

My practice is that default values are mostly, if not entirely,  
localized to the model or constrained within the DB schema. I depart  
from Rails orthodoxy on this issue and I selected my database backend  
(postgresql) with care so that significant amount of data integrity  
logic could be enforced by the database.

For development I want this sort of stuff close to the code so that I  
can easily adjust things without having to alter the DB overmuch. In  
production I anticipate that a good deal of the constraints and defaults  
will be moved from the model into the DBMS. Calculated fields are a  
distinct issue, as you point out, and on that matter the model indeed  
may be the best (perhaps only) place for them.

Thanks,