Rails 3.2, virtual accessor and deprecation warning - ruby-on-rails

I'm really confused about virtual attributes in Rails 3.2 and all my research haven't help making things clearer.
# input model
class Input < ActiveRecord::Base
# Attributes --------------------
attr_accessible :title, :parent
attr_accessor :parent
def parent=(id)
wrtite_attribute(:parent, id.to_i)
self.parent = id.to_i
self[:parent] = id.to_i
#parent = id.to_i # seems to be the only one working. Why?
end
end
# inputs controller
class InputsController < ApplicationController
def new
#input = Input.new({
start_date: #current_scope_company.creation_date,
parent: 'bla'
})
#input.parent = 'bla'
#input[;parent] = 'bla'
end
end
# inputs table
create_table "inputs", :force => true do |t|
t.string "title"
t.datetime "created_at", :null => false
t.datetime "updated_at", :null => false
end
Above, I have compiled pretty much all the alternatives I found on the internet. It is NOT the code I run, just couple versions of the same thing. Though, whatever I try, I get the following warning:
DEPRECATION WARNING: You're trying to create an attribute 'parent'. Writing arbitrary attributes on a model is deprecated. Please just use 'attr_writer' etc.
Sometimes, I even get a stack level too deep. I'd love to understand how attributes work.
1/ attr_accessor is attr_writer plus attr_reader right? Why am I asked to use attr_writer in the warning?
2/ How am I supposed to write attributes from the model (and why)
3/ How am I supposed to write attributes from the controller (and why)
Thanks a lot!
Update
After further test, it looks like the proper way to do it is #parent = id.to_i. I would still love to get explanation why. I'm really confused why self. wouldn't work.

Atttr_accessor should be fine. So in your model, it looks like you're trying to do the same thing in four different ways:
def parent=(id)
write_attribute(:parent, id.to_i)
self.parent = id.to_i
self[:parent] = id.to_i
#parent = id.to_i # <- all these are redundant and scary
end
(Furthermore, in your controller it looks like you're also trying to do the same thing in different ways, unnecessarily.) Also, I'm pretty sure the syntax 'def parent=(id)' is only for real attributes. Looking at this railscast and from my own experience, you just do something like this for a virtual attribute:
def parent
#id.to_i
end
Where is "id" coming from that's supposed to go into 'parent'? Virtual attributes have to somehow related to something that's actually being stored in the db, either through a real attribute or through an association's real attribute. If you explain a bit more of what parent is actually supposed to be calculated from, it'd be easier to help.

Related

SQL How to get only 1 true value

I am building an application and I need to be able to sing a lead teacher
I need to prevent that 2 teachers share the title of lead for a particular class
class CreateClassroomTeachers < ActiveRecord::Migration[5.2]
def change
create_table :classroom_teachers do |t|
t.belongs_to :classroom
t.belongs_to :teacher
t.boolean :lead, default: false
end
add_index :household_people, [:classroom_id, :teacher_id], unique: true
# Only one teacher in a classroom can be lead
end
end
I have this in my model
class ClassroomTeacher < ApplicationRecord
belongs_to :classroom
belongs_to :teacher
validate :only_one_is_lead_teacher
def only_one_is_lead_teacher
if lead
if ClassroomTeacher.where(classroom_id: classroom_id, lead: true).count > 0
errors.add(:lead, "There can only be one (1) lead teacher per classroom")
end
end
end
end
The problem on this is that on Create I can have 2 or more teachers be lead
Thanks for the help
There's several ways for achieving this with constraints, triggers etc. – depending on what your respective database server supports.
What should work at least in Postgres (even though it might be slightly hacky) is to set a unique index on %i[classroom_id lead] and make sure that lead is either true or NULL. This should work because Postgres treats NULL values as distinct, meaning that it doesn't complain if multiple NULL values are stored in a column that has a uniqueness constraint on it.
If you want to solve it in code (which personally I would not recommend, because your database might be access by things other than your code and even your code can work around it, e.g. by directly writing to the database instead of using ActiveRecord's higher level methods), here's how I've done this in the past:
class ClassroomTeacher < ActiveRecord::Base
before_save :ensure_only_one_lead_teacher
private
def ensure_only_one_lead_teacher
# We don't have to do this unless the record is the one who should be the (new) lead.
return unless lead?
# Set all other records for the class room to lead = false.
self.class.where(classroom_id: classroom_id).update_all(lead: false)
# Now if the record gets persisted, it will be the only one with lead = true.
end
end
A probably slightly more "correct" approach would be to ensure the uniqueness after the record has been persisted:
class ClassroomTeacher < ActiveRecord::Base
after_commit :ensure_only_one_lead_teacher
private
def ensure_only_one_lead_teacher
# We don't have to do this unless the record is the one who should be the (new) lead.
return unless lead?
# Set all other records for the class room to lead = false. Note that we now have to exclude
# the record itself by id because it has already been saved.
self.class.where.not(id: id).where(classroom_id: classroom_id).update_all(lead: false)
end
end
As per the migration, attributes for the model are
ClassroomTeacher: classroom_id, teacher_id, lead
Considering teachers are being added to class:
/controller file
def create
ClassroomTeacher.create(teacher_id: data1, classroom_id: data2, lead: data3)
end
Possible sample data with ideal values would be:
id classroom_id teacher_id lead
1 1 3 false
2 2 4 true
3 1 2 false
4 1 5 true
Now you need to avoid any new teachers being added to the classroom as lead. Model validation code could be
validate :only_one_is_lead_teacher
def only_one_is_lead_teacher
if self.lead
class_obj = ClassroomTeacher.where(classroom_id: self.classroom_id, lead: true).first
if class_obj.present?
self.errors.add(:lead, "There can only be one (1) lead teacher per classroom")
return false
end
end
end

Obfuscation of URLs - rails

I'm working on a project that's left me stumped, hoping someone out there might have some interesting input. I see there are several gems available for obfuscation of urls, but they seem to stop at the slug level instead of the controller level - i.e. www.foo.com/mycontroller/8sZ16lp. I'm looking for a method to produce something along the lines of www.foo.com/8asd31Ud, dropping the controller name. I checked the docs of the obsufacate_id gem, but it doesn't appear to go that far.
To give more background - I'm really hoping to have www.foo.com/mycontroller/15/edit = www.foo.com/95Ali32
As this doesn't match the convention of rails RESTful URL's my guess is you'll likely just need to write your own routes and maybe more. Out of curiosity, how would you envision that the system knows what type of object to load with "95Ali32"? This might be better to build with Sinatra or something that gives you more control over the routing and less convention.
Here's one possible approach that uses a table with your slugs that maps to type and object id:
# migration
create_table :slugs do |t|
t.string :object_type, :null => false
t.string :object_id, :null => false
t.string :slug
t.timestamps
end
# models
class Slugs < ActiveRecord::Base
belongs_to :object, :polymorhic => true
end
class AModel < ActiveRecord::Base
has_one :slug, :as => :owner
end
# routes.rb
# note that anything else should go above this because this will catch all other URL's
get '*slug', to: 'slugs#show'
# controller
class SlugsController < ApplicationController
def show
#object = Slug.where(slug: params[:slug])
raise ActiveRecord::NotFound.new unless #object
render #object.kind
end
end
You would then need to build views for each type of object. See this related question
Update
Here's another idea. How obscure do you need the slug? What if each model has a known code and then the ID is encoded some way and appended to the model code? Then you could do something much simpler in the code using routes that are preconfigured:
# You could generate this too, or just hard-code them
prefixes = ['8sZ', '95Ali']
[:a_model, :another_model].each do |model|
match "#{prefixes.pop}:id", :controller => model.to_s.underscore.pluralize, :action => :show, :as => model
end
This would give you routes like these
/8sZ1 #=> AModelsController#show(:id => 1)
/95Ali341 #=> AModelsController#show(:id => 341)
You could take this another level and use friendly_id to generate slugs for the model ID's. Or use UUID's instead of integer ID's (supported by PostgreSQL).

find_or_create_by versus before_save callbacks

I have a model that uses a callback to normalize one of its parameters, and that parameter is part of a unique key for the model. But when using MyModel.find_or_create_by(), the callback doesn't come into play during the 'find' phase, only the 'create' phase, by which it's too late.
Is there an elegant pattern for doing this? A contrived example:
class CreateMyModels < ActiveRecord::Migration
def change
create_table :my_models do |t|
t.float :value
end
add_index :my_models, :value, :unique => true
end
end
class MyModel < ActiveRecord::Base
before_save :quantize_value
private
def quantize_value
self.value = ((self.value || 0.0) * 256.0).round / 256.0
end
end
Let's try it out:
>> a = MyModel.find_or_create_by(:value => 0.501)
=> #<MyModel id: 1, value: 0.5>
So far, so good. If we find_or_create_by another whose value is close but not equal to the incumbent record, we'd like it to find the incumbent record. But instead we get:
>> b = MyModel.find_or_create_by(:value => 0.5001)
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint ...
What I'd like -- conceptually -- is to have the quantize_value method run before running the find.
Of course I've already written a custom constructor that applies the quantize_value method before running the find. But if experience has taught me anything, it's that the developers of Rails have already written the code that I think I need to write, and creating my own constructor would be replicating their work! :)
IMO, I would move the quantize logic out of the models saving callbacks and do it manually. You'd be more aware of what the actual values are instead of setting a value and then seeing the model modifying it.
If you really want to keep the logic inside the model, you can override the setter method for your attribute like below:
def value=(val)
self[:value] = quantitize_value(val)
end

How to set default values in Rails?

I'm trying to find the best way to set default values for objects in Rails.
The best I can think of is to set the default value in the new method in the controller.
Does anyone have any input if this is acceptable or if there's a better way to do it?
"Correct" is a dangerous word in Ruby. There's usually more than one way to do anything. If you know you'll always want that default value for that column on that table, setting them in a DB migration file is the easiest way:
class SetDefault < ActiveRecord::Migration
def self.up
change_column :people, :last_name, :type, :default => "Doe"
end
def self.down
# You can't currently remove default values in Rails
raise ActiveRecord::IrreversibleMigration, "Can't remove the default"
end
end
Because ActiveRecord autodiscovers your table and column properties, this will cause the same default to be set in any model using it in any standard Rails app.
However, if you only want default values set in specific cases -- say, it's an inherited model that shares a table with some others -- then another elegant way is do it directly in your Rails code when the model object is created:
class GenericPerson < Person
def initialize(attributes=nil)
attr_with_defaults = {:last_name => "Doe"}.merge(attributes)
super(attr_with_defaults)
end
end
Then, when you do a GenericPerson.new(), it'll always trickle the "Doe" attribute up to Person.new() unless you override it with something else.
Based on SFEley's answer, here is an updated/fixed one for newer Rails versions:
class SetDefault < ActiveRecord::Migration
def change
change_column :table_name, :column_name, :type, default: "Your value"
end
end
First of all you can't overload initialize(*args) as it's not called in all cases.
Your best option is to put your defaults into your migration:
add_column :accounts, :max_users, :integer, :default => 10
Second best is to place defaults into your model but this will only work with attributes that are initially nil. You may have trouble as I did with boolean columns:
def after_initialize
if new_record?
max_users ||= 10
end
end
You need the new_record? so the defaults don't override values loaded from the datbase.
You need ||= to stop Rails from overriding parameters passed into the initialize method.
You can also try change_column_default in your migrations (tested in Rails 3.2.8):
class SetDefault < ActiveRecord::Migration
def up
# Set default value
change_column_default :people, :last_name, "Smith"
end
def down
# Remove default
change_column_default :people, :last_name, nil
end
end
change_column_default Rails API docs
If you are referring to ActiveRecord objects, you have (more than) two ways of doing this:
1. Use a :default parameter in the DB
E.G.
class AddSsl < ActiveRecord::Migration
def self.up
add_column :accounts, :ssl_enabled, :boolean, :default => true
end
def self.down
remove_column :accounts, :ssl_enabled
end
end
More info here: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
2. Use a callback
E.G. before_validation_on_create
More info here: http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html#M002147
In Ruby on Rails v3.2.8, using the after_initialize ActiveRecord callback, you can call a method in your model that will assign the default values for a new object.
after_initialize callback is triggered for each object that is found and instantiated by a finder, with after_initialize being triggered after new objects are instantiated as well
(see ActiveRecord Callbacks).
So, IMO it should look something like:
class Foo < ActiveRecord::Base
after_initialize :assign_defaults_on_new_Foo
...
attr_accessible :bar
...
private
def assign_defaults_on_new_Foo
# required to check an attribute for existence to weed out existing records
self.bar = default_value unless self.attribute_whose_presence_has_been_validated
end
end
Foo.bar = default_value for this instance unless the instance contains an attribute_whose_presence_has_been_validated previously on save/update. The default_value will then be used in conjunction with your view to render the form using the default_value for the bar attribute.
At best this is hacky...
EDIT - use 'new_record?' to check if instantiating from a new call
Instead of checking an attribute value, use the new_record? built-in method with rails. So, the above example should look like:
class Foo < ActiveRecord::Base
after_initialize :assign_defaults_on_new_Foo, if: 'new_record?'
...
attr_accessible :bar
...
private
def assign_defaults_on_new_Foo
self.bar = default_value
end
end
This is much cleaner. Ah, the magic of Rails - it's smarter than me.
In case you're dealing with a Model, you can use the Attriutes API in Rails 5+
http://api.rubyonrails.org/classes/ActiveRecord/Attributes/ClassMethods.html#method-i-attribute
just add a migration with a proper column name and then in the model set it with:
class StoreListing < ActiveRecord::Base
attribute :country, :string, default: 'PT'
end
For boolean fields in Rails 3.2.6 at least, this will work in your migration.
def change
add_column :users, :eula_accepted, :boolean, default: false
end
Putting a 1 or 0 for a default will not work here, since it is a boolean field. It must be a true or false value.
Generate a migration and use change_column_default, is succinct and reversible:
class SetDefaultAgeInPeople < ActiveRecord::Migration[5.2]
def change
change_column_default :people, :age, { from: nil, to: 0 }
end
end
If you are just setting defaults for certain attributes of a database backed model I'd consider using sql default column values - can you clarify what types of defaults you are using?
There are a number of approaches to handle it, this plugin looks like an interesting option.
The suggestion to override new/initialize is probably incomplete. Rails will (frequently) call allocate for ActiveRecord objects, and calls to allocate won't result in calls to initialize.
If you're talking about ActiveRecord objects, take a look at overriding after_initialize.
These blog posts (not mine) are useful:
Default values
Default constructors not called
[Edit: SFEley points out that Rails actually does look at the default in the database when it instantiates a new object in memory - I hadn't realized that.]
I needed to set a default just as if it was specified as default column value in DB. So it behaves like this
a = Item.new
a.published_at # => my default value
a = Item.new(:published_at => nil)
a.published_at # => nil
Because after_initialize callback is called after setting attributes from arguments, there was no way to know if the attribute is nil because it was never set or because it was intentionally set as nil. So I had to poke inside a bit and came with this simple solution.
class Item < ActiveRecord::Base
def self.column_defaults
super.merge('published_at' => Time.now)
end
end
Works great for me. (Rails 3.2.x)
A potentially even better/cleaner potential way than the answers proposed is to overwrite the accessor, like this:
def status
self['name_of_var'] || 'desired_default_value'
end
See "Overwriting default accessors" in the ActiveRecord::Base documentation and more from StackOverflow on using self.
i answered a similar question here.. a clean way to do this is using Rails attr_accessor_with_default
class SOF
attr_accessor_with_default :is_awesome,true
end
sof = SOF.new
sof.is_awesome
=> true
UPDATE
attr_accessor_with_default has been deprecated in Rails 3.2.. you could do this instead with pure Ruby
class SOF
attr_writer :is_awesome
def is_awesome
#is_awesome ||= true
end
end
sof = SOF.new
sof.is_awesome
#=> true
If you're talking about ActiveRecord objects, I use the 'attribute-defaults' gem.
Documentation & download: https://github.com/bsm/attribute-defaults
You could use the rails_default_value gem. eg:
class Foo < ActiveRecord::Base
# ...
default :bar => 'some default value'
# ...
end
https://github.com/keithrowell/rails_default_value
You can override the constructor for the ActiveRecord model.
Like this:
def initialize(*args)
super(*args)
self.attribute_that_needs_default_value ||= default_value
self.attribute_that_needs_another_default_value ||= another_default_value
#ad nauseum
end

Rails: How can I set default values in ActiveRecord?

How can I set default value in ActiveRecord?
I see a post from Pratik that describes an ugly, complicated chunk of code: http://m.onkey.org/2007/7/24/how-to-set-default-values-in-your-model
class Item < ActiveRecord::Base
def initialize_with_defaults(attrs = nil, &block)
initialize_without_defaults(attrs) do
setter = lambda { |key, value| self.send("#{key.to_s}=", value) unless
!attrs.nil? && attrs.keys.map(&:to_s).include?(key.to_s) }
setter.call('scheduler_type', 'hotseat')
yield self if block_given?
end
end
alias_method_chain :initialize, :defaults
end
I have seen the following examples googling around:
def initialize
super
self.status = ACTIVE unless self.status
end
and
def after_initialize
return unless new_record?
self.status = ACTIVE
end
I've also seen people put it in their migration, but I'd rather see it defined in the model code.
Is there a canonical way to set default value for fields in ActiveRecord model?
There are several issues with each of the available methods, but I believe that defining an after_initialize callback is the way to go for the following reasons:
default_scope will initialize values for new models, but then that will become the scope on which you find the model. If you just want to initialize some numbers to 0 then this is not what you want.
Defining defaults in your migration also works part of the time... As has already been mentioned this will not work when you just call Model.new.
Overriding initialize can work, but don't forget to call super!
Using a plugin like phusion's is getting a bit ridiculous. This is ruby, do we really need a plugin just to initialize some default values?
Overriding after_initialize is deprecated as of Rails 3. When I override after_initialize in rails 3.0.3 I get the following warning in the console:
DEPRECATION WARNING: Base#after_initialize has been deprecated, please use Base.after_initialize :method instead. (called from /Users/me/myapp/app/models/my_model:15)
Therefore I'd say write an after_initialize callback, which lets you default attributes in addition to letting you set defaults on associations like so:
class Person < ActiveRecord::Base
has_one :address
after_initialize :init
def init
self.number ||= 0.0 #will set the default value only if it's nil
self.address ||= build_address #let's you set a default association
end
end
Now you have just one place to look for initialization of your models. I'm using this method until someone comes up with a better one.
Caveats:
For boolean fields do:
self.bool_field = true if self.bool_field.nil?
See Paul Russell's comment on this answer for more details
If you're only selecting a subset of columns for a model (ie; using select in a query like Person.select(:firstname, :lastname).all) you will get a MissingAttributeError if your init method accesses a column that hasn't been included in the select clause. You can guard against this case like so:
self.number ||= 0.0 if self.has_attribute? :number
and for a boolean column...
self.bool_field = true if (self.has_attribute? :bool_value) && self.bool_field.nil?
Also note that the syntax is different prior to Rails 3.2 (see Cliff Darling's comment below)
Rails 5+
You can use the attribute method within your models, eg.:
class Account < ApplicationRecord
attribute :locale, :string, default: 'en'
end
You can also pass a lambda to the default parameter. Example:
attribute :uuid, :string, default: -> { SecureRandom.uuid }
The second argument is the type and it can also be a custom type class instance, for example:
attribute :uuid, UuidType.new, default: -> { SecureRandom.uuid }
We put the default values in the database through migrations (by specifying the :default option on each column definition) and let Active Record use these values to set the default for each attribute.
IMHO, this approach is aligned with the principles of AR : convention over configuration, DRY, the table definition drives the model, not the other way around.
Note that the defaults are still in the application (Ruby) code, though not in the model but in the migration(s).
Some simple cases can be handled by defining a default in the database schema but that doesn't handle a number of trickier cases including calculated values and keys of other models. For these cases I do this:
after_initialize :defaults
def defaults
unless persisted?
self.extras||={}
self.other_stuff||="This stuff"
self.assoc = [OtherModel.find_by_name('special')]
end
end
I've decided to use the after_initialize but I don't want it to be applied to objects that are found only those new or created. I think it is almost shocking that an after_new callback isn't provided for this obvious use case but I've made do by confirming whether the object is already persisted indicating that it isn't new.
Having seen Brad Murray's answer this is even cleaner if the condition is moved to callback request:
after_initialize :defaults, unless: :persisted?
# ":if => :new_record?" is equivalent in this context
def defaults
self.extras||={}
self.other_stuff||="This stuff"
self.assoc = [OtherModel.find_by_name('special')]
end
The after_initialize callback pattern can be improved by simply doing the following
after_initialize :some_method_goes_here, :if => :new_record?
This has a non-trivial benefit if your init code needs to deal with associations, as the following code triggers a subtle n+1 if you read the initial record without including the associated.
class Account
has_one :config
after_initialize :init_config
def init_config
self.config ||= build_config
end
end
The Phusion guys have some nice plugin for this.
An even better/cleaner potential way than the answers proposed is to overwrite the accessor, like this:
def status
self['status'] || ACTIVE
end
See "Overwriting default accessors" in the ActiveRecord::Base documentation and more from StackOverflow on using self.
I use the attribute-defaults gem
From the documentation:
run sudo gem install attribute-defaults and add require 'attribute_defaults' to your app.
class Foo < ActiveRecord::Base
attr_default :age, 18
attr_default :last_seen do
Time.now
end
end
Foo.new() # => age: 18, last_seen => "2014-10-17 09:44:27"
Foo.new(:age => 25) # => age: 25, last_seen => "2014-10-17 09:44:28"
Similar questions, but all have slightly different context:
- How do I create a default value for attributes in Rails activerecord's model?
Best Answer: Depends on What You Want!
If you want every object to start with a value: use after_initialize :init
You want the new.html form to have a default value upon opening the page? use https://stackoverflow.com/a/5127684/1536309
class Person < ActiveRecord::Base
has_one :address
after_initialize :init
def init
self.number ||= 0.0 #will set the default value only if it's nil
self.address ||= build_address #let's you set a default association
end
...
end
If you want every object to have a value calculated from user input: use before_save :default_values
You want user to enter X and then Y = X+'foo'? use:
class Task < ActiveRecord::Base
before_save :default_values
def default_values
self.status ||= 'P'
end
end
I've also seen people put it in their migration, but I'd rather see it
defined in the model code.
Is there a canonical way to set default value for fields in
ActiveRecord model?
The canonical Rails way, before Rails 5, was actually to set it in the migration, and just look in the db/schema.rb for whenever wanting to see what default values are being set by the DB for any model.
Contrary to what #Jeff Perrin answer states (which is a bit old), the migration approach will even apply the default when using Model.new, due to some Rails magic. Verified working in Rails 4.1.16.
The simplest thing is often the best. Less knowledge debt and potential points of confusion in the codebase. And it 'just works'.
class AddStatusToItem < ActiveRecord::Migration
def change
add_column :items, :scheduler_type, :string, { null: false, default: "hotseat" }
end
end
Or, for column change without creating a new one, then do either:
class AddStatusToItem < ActiveRecord::Migration
def change
change_column_default :items, :scheduler_type, "hotseat"
end
end
Or perhaps even better:
class AddStatusToItem < ActiveRecord::Migration
def change
change_column :items, :scheduler_type, :string, default: "hotseat"
end
end
Check the official RoR guide for options in column change methods.
The null: false disallows NULL values in the DB, and, as an added benefit, it also updates so that all pre-existing DB records that were previously null is set with the default value for this field as well. You may exclude this parameter in the migration if you wish, but I found it very handy!
The canonical way in Rails 5+ is, as #Lucas Caton said:
class Item < ActiveRecord::Base
attribute :scheduler_type, :string, default: 'hotseat'
end
This is what constructors are for! Override the model's initialize method.
Use the after_initialize method.
Sup guys, I ended up doing the following:
def after_initialize
self.extras||={}
self.other_stuff||="This stuff"
end
Works like a charm!
Rails 6.1+
You can now use the attribute method on your model without setting a type.
attribute :status, default: ACTIVE
or
class Account < ApplicationRecord
attribute :locale, default: 'en'
end
Note that feeding a default to attribute cannot reference the instance of the class (a lambda will execute in the context of the class, not the instance). So, if you need to set the default to a value dynamically based on the instance or associations, you're still going to have to use an alternative, such as an after_initialize callback. As stated previously, it's recommended to limit this to new records only to avoid n+1 queries if you reference associations.
after_initialize :do_something_that_references_instance_or_associations, if: :new_record?
This has been answered for a long time, but I need default values frequently and prefer not to put them in the database. I create a DefaultValues concern:
module DefaultValues
extend ActiveSupport::Concern
class_methods do
def defaults(attr, to: nil, on: :initialize)
method_name = "set_default_#{attr}"
send "after_#{on}", method_name.to_sym
define_method(method_name) do
if send(attr)
send(attr)
else
value = to.is_a?(Proc) ? to.call : to
send("#{attr}=", value)
end
end
private method_name
end
end
end
And then use it in my models like so:
class Widget < ApplicationRecord
include DefaultValues
defaults :category, to: 'uncategorized'
defaults :token, to: -> { SecureRandom.uuid }
end
I ran into problems with after_initialize giving ActiveModel::MissingAttributeError errors when doing complex finds:
eg:
#bottles = Bottle.includes(:supplier, :substance).where(search).order("suppliers.name ASC").paginate(:page => page_no)
"search" in the .where is hash of conditions
So I ended up doing it by overriding initialize in this way:
def initialize
super
default_values
end
private
def default_values
self.date_received ||= Date.current
end
The super call is necessary to make sure the object initializing correctly from ActiveRecord::Base before doing my customize code, ie: default_values
after_initialize method is deprecated, use the callback instead.
after_initialize :defaults
def defaults
self.extras||={}
self.other_stuff||="This stuff"
end
however, using :default in your migrations is still the cleanest way.
The problem with the after_initialize solutions is that you have to add an after_initialize to every single object you look up out of the DB, regardless of whether you access this attribute or not. I suggest a lazy-loaded approach.
The attribute methods (getters) are of course methods themselves, so you can override them and provide a default. Something like:
Class Foo < ActiveRecord::Base
# has a DB column/field atttribute called 'status'
def status
(val = read_attribute(:status)).nil? ? 'ACTIVE' : val
end
end
Unless, like someone pointed out, you need to do Foo.find_by_status('ACTIVE'). In that case I think you'd really need to set the default in your database constraints, if the DB supports it.
class Item < ActiveRecord::Base
def status
self[:status] or ACTIVE
end
before_save{ self.status ||= ACTIVE }
end
I strongly suggest using the "default_value_for" gem: https://github.com/FooBarWidget/default_value_for
There are some tricky scenarios that pretty much require overriding the initialize method, which that gem does.
Examples:
Your db default is NULL, your model/ruby-defined default is "some string", but you actually want to set the value to nil for whatever reason: MyModel.new(my_attr: nil)
Most solutions here will fail to set the value to nil, and will instead set it to the default.
OK, so instead of taking the ||= approach, you switch to my_attr_changed?...
BUT now imagine your db default is "some string", your model/ruby-defined default is "some other string", but under a certain scenario, you want to set the value to "some string" (the db default): MyModel.new(my_attr: 'some_string')
This will result in my_attr_changed? being false because the value matches the db default, which in turn will fire your ruby-defined default code and set the value to "some other string" -- again, not what you desired.
For those reasons I don't think this can properly be accomplished with just an after_initialize hook.
Again, I think the "default_value_for" gem is taking the right approach: https://github.com/FooBarWidget/default_value_for
Although doing that for setting default values is confusing and awkward in most cases, you can use :default_scope as well. Check out squil's comment here.
I've found that using a validation method provides a lot of control over setting defaults. You can even set defaults (or fail validation) for updates. You even set a different default value for inserts vs updates if you really wanted to.
Note that the default won't be set until #valid? is called.
class MyModel
validate :init_defaults
private
def init_defaults
if new_record?
self.some_int ||= 1
elsif some_int.nil?
errors.add(:some_int, "can't be blank on update")
end
end
end
Regarding defining an after_initialize method, there could be performance issues because after_initialize is also called by each object returned by :find :
http://guides.rubyonrails.org/active_record_validations_callbacks.html#after_initialize-and-after_find
If the column happens to be a 'status' type column, and your model lends itself to the use of state machines, consider using the aasm gem, after which you can simply do
aasm column: "status" do
state :available, initial: true
state :used
# transitions
end
It still doesn't initialize the value for unsaved records, but it's a bit cleaner than rolling your own with init or whatever, and you reap the other benefits of aasm such as scopes for all your statuses.
https://github.com/keithrowell/rails_default_value
class Task < ActiveRecord::Base
default :status => 'active'
end
Here's a solution I've used that I was a little surprised hasn't been added yet.
There are two parts to it. First part is setting the default in the actual migration, and the second part is adding a validation in the model ensuring that the presence is true.
add_column :teams, :new_team_signature, :string, default: 'Welcome to the Team'
So you'll see here that the default is already set. Now in the validation you want to ensure that there is always a value for the string, so just do
validates :new_team_signature, presence: true
What this will do is set the default value for you. (for me I have "Welcome to the Team"), and then it will go one step further an ensure that there always is a value present for that object.
Hope that helps!
# db/schema.rb
create_table :store_listings, force: true do |t|
t.string :my_string, default: "original default"
end
StoreListing.new.my_string # => "original default"
# app/models/store_listing.rb
class StoreListing < ActiveRecord::Base
attribute :my_string, :string, default: "new default"
end
StoreListing.new.my_string # => "new default"
class Product < ActiveRecord::Base
attribute :my_default_proc, :datetime, default: -> { Time.now }
end
Product.new.my_default_proc # => 2015-05-30 11:04:48 -0600
sleep 1
Product.new.my_default_proc # => 2015-05-30 11:04:49 -0600
I had a similar challenge when working on a Rails 6 application.
Here's how I solved it:
I have a Users table and a Roles table. The Users table belongs to the Roles table. I also have an Admin and Student Models that inherit from the Users table.
It then required that I set a default value for the role whenever a user is created, say admin role that has an id = 1 or student role that has an id = 2.
class User::Admin < User
before_save :default_values
def default_values
# set role_id to '1' except if role_id is not empty
return self.role_id = '1' unless role_id.nil?
end
end
This means that before an admin user is created/saved in the database the role_id is set to a default of 1 if it is not empty.
return self.role_id = '1' unless role_id.nil?
is the same as:
return self.role_id = '1' unless self.role_id.nil?
and the same as:
self.role_id = '1' if role_id.nil?
but the first one is cleaner and more precise.
That's all.
I hope this helps
Been using this for a while.
# post.rb
class Post < ApplicationRecord
attribute :country, :string, default: 'ID'
end
use default_scope in rails 3
api doc
ActiveRecord obscures the difference between defaulting defined in the database (schema) and defaulting done in the application (model). During initialization, it parses the database schema and notes any default values specified there. Later, when creating objects, it assigns those schema-specified default values without touching the database.
discussion
From the api docs http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html
Use the before_validation method in your model, it gives you the options of creating specific initialisation for create and update calls
e.g. in this example (again code taken from the api docs example) the number field is initialised for a credit card. You can easily adapt this to set whatever values you want
class CreditCard < ActiveRecord::Base
# Strip everything but digits, so the user can specify "555 234 34" or
# "5552-3434" or both will mean "55523434"
before_validation(:on => :create) do
self.number = number.gsub(%r[^0-9]/, "") if attribute_present?("number")
end
end
class Subscription < ActiveRecord::Base
before_create :record_signup
private
def record_signup
self.signed_up_on = Date.today
end
end
class Firm < ActiveRecord::Base
# Destroys the associated clients and people when the firm is destroyed
before_destroy { |record| Person.destroy_all "firm_id = #{record.id}" }
before_destroy { |record| Client.destroy_all "client_of = #{record.id}" }
end
Surprised that his has not been suggested here

Resources