Very Important in has

The has_one association supports these options:

:as
:autosave
:class_name
:dependent
:foreign_key
:inverse_of
:primary_key
:source
:source_type
:through
:touch
:validate

4.2.2.1 `:as`

Setting the :as option indicates that this is a polymorphic association. Polymorphic associations were discussed in detail earlier in this guide.

If you set the :autosave option to true, Rails will save any loaded association members and destroy members that are marked for destruction whenever you save the parent object. Setting :autosave to false is not the same as not setting the :autosave option. If the :autosave option is not present, then new associated objects will be saved, but updated associated objects will not be saved.

4.2.2.3 `:class_name`

If the name of the other model cannot be derived from the association name, you can use the :class_name option to supply the model name. For example, if a supplier has an account, but the actual name of the model containing accounts is Billing, you'd set things up this way:

class Supplier < ApplicationRecord
  has_one :account, class_name: "Billing"
end

4.2.2.4 `:dependent`

Controls what happens to the associated object when its owner is destroyed:

:destroy causes the associated object to also be destroyed
:delete causes the associated object to be deleted directly from the database (so callbacks will not execute)
:nullify causes the foreign key to be set to NULL. Polymorphic type column is also nullified on polymorphic associations. Callbacks are not executed.
:restrict_with_exception causes an ActiveRecord::DeleteRestrictionError exception to be raised if there is an associated record
:restrict_with_error causes an error to be added to the owner if there is an associated object

It's necessary not to set or leave :nullify option for those associations that have NOT NULL database constraints. If you don't set dependent to destroy such associations you won't be able to change the associated object because the initial associated object's foreign key will be set to the unallowed NULL value.

4.2.2.5 `:foreign_key`

By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix _id added. The :foreign_key option lets you set the name of the foreign key directly:

class Supplier < ApplicationRecord
  has_one :account, foreign_key: "supp_id"
end

In any case, Rails will not create foreign key columns for you. You need to explicitly define them as part of your migrations.

4.2.2.6 `:inverse_of`

The :inverse_of option specifies the name of the belongs_to association that is the inverse of this association.

class Supplier < ApplicationRecord
  has_one :account, inverse_of: :supplier
end
 
class Account < ApplicationRecord
  belongs_to :supplier, inverse_of: :account
end

4.2.2.7 `:primary_key`

By convention, Rails assumes that the column used to hold the primary key of this model is id. You can override this and explicitly specify the primary key with the :primary_key option.

4.2.2.8 `:source`

The :source option specifies the source association name for a has_one :through association.

4.2.2.9 `:source_type`

The :source_type option specifies the source association type for a has_one :through association that proceeds through a polymorphic association.

class Book < ApplicationRecord
  has_one :format, polymorphic: true
  has_one :dust_jacket, through: :format, source: :dust_jacket, source_type: "Hardback"
end
 
class Paperback < ApplicationRecord; end
 
class Hardback < ApplicationRecord
  has_one :dust_jacket
end
 
class DustJacket < ApplicationRecord; end

4.2.2.10 `:through`

The :through option specifies a join model through which to perform the query. has_one :through associations were discussed in detail earlier in this guide.

4.2.2.11 `:touch`

If you set the :touch option to true, then the updated_at or updated_on timestamp on the associated object will be set to the current time whenever this object is saved or destroyed:

class Supplier < ApplicationRecord
  has_one :account, touch: true
end
 
class Account < ApplicationRecord
  belongs_to :supplier
end

In this case, saving or destroying a supplier will update the timestamp on the associated account. You can also specify a particular timestamp attribute to update:

class Supplier < ApplicationRecord
  has_one :account, touch: :suppliers_updated_at
end

4.2.2.12 `:validate`

If you set the :validate option to true, then associated objects will be validated whenever you save this object. By default, this is false: associated objects will not be validated when this object is saved.

Search This Blog

Dwijendra Parashar