Comment puis-je définir la valeur par défaut dans ActiveRecord?

Je vois un article de Pratik qui décrit un morceau de code laid et compliqué: 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

J'ai vu les exemples suivants googler autour:

  def initialize 
    super
    self.status = ACTIVE unless self.status
  end

et

  def after_initialize 
    return unless new_record?
    self.status = ACTIVE
  end

J'ai également vu des gens le mettre dans leur migration, mais je préfère le voir défini dans le code du modèle.

Existe-t-il un moyen canonique de définir la valeur par défaut des champs dans le modèle ActiveRecord?

Il existe plusieurs problèmes avec chacune des méthodes disponibles, mais je pense que la définition d'un after_initializerappel est la voie à suivre pour les raisons suivantes:

1. default_scopeinitialisera les valeurs des nouveaux modèles, mais cela deviendra alors l'étendue sur laquelle vous trouverez le modèle. Si vous voulez simplement initialiser certains nombres à 0, ce n'est pas ce que vous voulez.
2. La définition des valeurs par défaut dans votre migration fonctionne également une partie du temps ... Comme cela a déjà été mentionné, cela ne fonctionnera pas lorsque vous appelez simplement Model.new.
3. Le remplacement initializepeut fonctionner, mais n'oubliez pas d'appeler super!
4. Utiliser un plugin comme Phusion est un peu ridicule. C'est ruby, avons-nous vraiment besoin d'un plugin juste pour initialiser certaines valeurs par défaut?
5. Le remplacement after_initialize est obsolète à partir de Rails 3. Lorsque je remplace after_initializedans rails 3.0.3, j'obtiens l'avertissement suivant dans la console:

AVERTISSEMENT DEPRECATION: Base # after_initialize a été dépréciée, veuillez utiliser la méthode Base.after_initialize: à la place. (appelé depuis / Users / me / myapp / app / models / my_model: 15)

Par conséquent, je dirais écrire un after_initializerappel, qui vous permet de définir des attributs par défaut en plus de vous permettre de définir des valeurs par défaut sur des associations telles que:

  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    

Maintenant, vous n'avez qu'un seul endroit où chercher pour l'initialisation de vos modèles. J'utilise cette méthode jusqu'à ce que quelqu'un en trouve une meilleure.

Mises en garde:

1. Pour les champs booléens, faites:

   self.bool_field = true if self.bool_field.nil?

   Voir le commentaire de Paul Russell sur cette réponse pour plus de détails

2. Si vous ne sélectionnez qu'un sous-ensemble de colonnes pour un modèle (c'est-à-dire, en l'utilisant selectdans une requête comme Person.select(:firstname, :lastname).all), vous obtiendrez un MissingAttributeErrorsi votre initméthode accède à une colonne qui n'a pas été incluse dans la selectclause. Vous pouvez vous prémunir contre ce cas comme ceci:

   self.number ||= 0.0 if self.has_attribute? :number

   et pour une colonne booléenne ...

   self.bool_field = true if (self.has_attribute? :bool_value) && self.bool_field.nil?

   Notez également que la syntaxe est différente avant Rails 3.2 (voir le commentaire de Cliff Darling ci-dessous)

Rails 5+

Vous pouvez utiliser la méthode d' attribut dans vos modèles, par exemple:

class Account < ApplicationRecord
  attribute :locale, :string, default: 'en'
end

Vous pouvez également passer un lambda au default paramètre. Exemple:

attribute :uuid, UuidType.new, default: -> { SecureRandom.uuid }

Nous plaçons les valeurs par défaut dans la base de données lors des migrations (en spécifiant l' :defaultoption sur chaque définition de colonne) et laissons Active Record utiliser ces valeurs pour définir la valeur par défaut pour chaque attribut.

À mon humble avis, cette approche est alignée sur les principes de la réalité augmentée: convention sur la configuration, SEC, la définition de la table pilote le modèle, et non l'inverse.

Notez que les valeurs par défaut sont toujours dans le code d'application (Ruby), mais pas dans le modèle mais dans la ou les migrations.

Certains cas simples peuvent être traités en définissant une valeur par défaut dans le schéma de base de données, mais cela ne gère pas un certain nombre de cas plus délicats, y compris les valeurs calculées et les clés d'autres modèles. Pour ces cas, je fais ceci:

after_initialize :defaults

def defaults
   unless persisted?
    self.extras||={}
    self.other_stuff||="This stuff"
    self.assoc = [OtherModel.find_by_name('special')]
  end
end

J'ai décidé d'utiliser l'after_initialize mais je ne veux pas qu'il soit appliqué aux objets qui ne sont trouvés que ceux nouveaux ou créés. Je pense qu'il est presque choquant qu'un rappel after_new ne soit pas fourni pour ce cas d'utilisation évident, mais je l'ai fait en confirmant si l'objet est déjà persisté indiquant qu'il n'est pas nouveau.

Après avoir vu la réponse de Brad Murray, cela est encore plus propre si la condition est déplacée vers la demande de rappel:

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

Le modèle de rappel after_initialize peut être amélioré en procédant simplement comme suit

after_initialize :some_method_goes_here, :if => :new_record?

Cela présente un avantage non trivial si votre code init doit traiter avec des associations, car le code suivant déclenche un subtil n + 1 si vous lisez l'enregistrement initial sans inclure celui associé.

class Account

  has_one :config
  after_initialize :init_config

  def init_config
    self.config ||= build_config
  end

end

Les gars de Phusion ont un joli plugin pour ça.

Un moyen potentiel encore meilleur / plus propre que les réponses proposées est de remplacer l'accesseur, comme ceci:

def status
  self['status'] || ACTIVE
end

Voir «Écraser les accesseurs par défaut» dans la documentation ActiveRecord :: Base et plus de StackOverflow sur l'utilisation de self .

J'utilise le attribute-defaultsbijou

À partir de la documentation: exécutez sudo gem install attribute-defaultset ajoutez require 'attribute_defaults'à votre application.

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"

Des questions similaires, mais toutes ont un contexte légèrement différent: - Comment créer une valeur par défaut pour les attributs dans le modèle de Rails activerecord?

Meilleure réponse: dépend de ce que vous voulez!

Si vous voulez que chaque objet commence par une valeur: utilisezafter_initialize :init

Vous souhaitez que le new.htmlformulaire ait une valeur par défaut à l'ouverture de la page? utilisez 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 

Si vous voulez que chaque objet ait une valeur calculée à partir de l'entrée utilisateur: utilisezbefore_save :default_values Vous voulez que l'utilisateur entreXet ensuiteY = X+'foo'? utilisation:

class Task < ActiveRecord::Base
  before_save :default_values
  def default_values
    self.status ||= 'P'
  end
end

C'est à ça que servent les constructeurs! Remplacez la initializeméthode du modèle .

Utilisez la after_initializeméthode.

Les gars Sup, j'ai fini par faire ce qui suit:

def after_initialize 
 self.extras||={}
 self.other_stuff||="This stuff"
end

Fonctionne comme un charme!

Cela a été répondu depuis longtemps, mais j'ai souvent besoin de valeurs par défaut et je préfère ne pas les mettre dans la base de données. Je crée une DefaultValuespréoccupation:

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

Et puis utilisez-le dans mes modèles comme ceci:

class Widget < ApplicationRecord
  include DefaultValues

  defaults :category, to: 'uncategorized'
  defaults :token, to: -> { SecureRandom.uuid }
end

J'ai également vu des gens le mettre dans leur migration, mais je préfère le voir défini dans le code du modèle.

Existe-t-il un moyen canonique de définir la valeur par défaut des champs dans le modèle ActiveRecord?

La manière canonique de Rails, avant Rails 5, était en fait de le définir dans la migration, et de simplement chercher dans le db/schema.rbpour chaque fois que vous voulez voir quelles valeurs par défaut sont définies par la base de données pour n'importe quel modèle.

Contrairement à ce que dit @Jeff Perrin (qui est un peu ancien), l'approche de la migration appliquera même la valeur par défaut lors de l'utilisation Model.new, en raison de la magie de Rails. Travail vérifié dans Rails 4.1.16.

La chose la plus simple est souvent la meilleure. Moins de dette de connaissances et de points de confusion potentiels dans la base de code. Et cela «fonctionne tout simplement».

class AddStatusToItem < ActiveRecord::Migration
  def change
    add_column :items, :scheduler_type, :string, { null: false, default: "hotseat" }
  end
end

Ou, pour un changement de colonne sans en créer un nouveau, effectuez l'une des opérations suivantes:

class AddStatusToItem < ActiveRecord::Migration
  def change
    change_column_default :items, :scheduler_type, "hotseat"
  end
end

Ou peut-être encore mieux:

class AddStatusToItem < ActiveRecord::Migration
  def change
    change_column :items, :scheduler_type, :string, default: "hotseat"
  end
end

Consultez le guide RoR officiel pour les options de méthodes de changement de colonne.

Le null: falsen'autorise pas les valeurs NULL dans la base de données et, comme avantage supplémentaire, il est également mis à jour afin que tous les enregistrements de base de données préexistants qui étaient auparavant nuls soient également définis avec la valeur par défaut pour ce champ. Vous pouvez exclure ce paramètre dans la migration si vous le souhaitez, mais je l'ai trouvé très pratique!

La voie canonique dans Rails 5+ est, comme l'a dit @Lucas Caton:

class Item < ActiveRecord::Base
  attribute :scheduler_type, :string, default: 'hotseat'
end

Le problème avec les solutions after_initialize est que vous devez ajouter un after_initialize à chaque objet que vous recherchez hors de la base de données, que vous accédiez ou non à cet attribut. Je suggère une approche paresseuse.

Les méthodes d'attribut (getters) sont bien sûr des méthodes elles-mêmes, vous pouvez donc les remplacer et fournir une valeur par défaut. Quelque chose comme:

Class Foo < ActiveRecord::Base
  # has a DB column/field atttribute called 'status'
  def status
    (val = read_attribute(:status)).nil? ? 'ACTIVE' : val
  end
end

À moins que, comme quelqu'un l'a souligné, vous devez faire Foo.find_by_status ('ACTIVE'). Dans ce cas, je pense que vous auriez vraiment besoin de définir la valeur par défaut dans vos contraintes de base de données, si la base de données le prend en charge.

J'ai rencontré des problèmes pour after_initializedonner des ActiveModel::MissingAttributeErrorerreurs lors de recherches complexes:

par exemple:

@bottles = Bottle.includes(:supplier, :substance).where(search).order("suppliers.name ASC").paginate(:page => page_no)

"recherche" dans le .wherehachage de conditions

J'ai donc fini par le faire en remplaçant initialize de cette façon:

def initialize
  super
  default_values
end

private
 def default_values
     self.date_received ||= Date.current
 end

L' superappel est nécessaire pour s'assurer que l'objet s'initialise correctement ActiveRecord::Baseavant de faire mon code de personnalisation, ie: default_values

class Item < ActiveRecord::Base
  def status
    self[:status] or ACTIVE
  end

  before_save{ self.status ||= ACTIVE }
end

Bien que faire cela pour définir des valeurs par défaut soit déroutant et gênant dans la plupart des cas, vous pouvez également l'utiliser :default_scope. Découvrez le commentaire de Squil ici .

La méthode after_initialize est obsolète, utilisez plutôt le rappel.

after_initialize :defaults

def defaults
  self.extras||={}
  self.other_stuff||="This stuff"
end

cependant, utiliser : default dans vos migrations est toujours le moyen le plus propre.

J'ai trouvé que l'utilisation d'une méthode de validation fournit beaucoup de contrôle sur la définition des valeurs par défaut. Vous pouvez même définir des valeurs par défaut (ou échouer la validation) pour les mises à jour. Vous définissez même une valeur par défaut différente pour les insertions et les mises à jour si vous le souhaitez vraiment. Notez que la valeur par défaut ne sera pas définie tant que #valid? est appelé.

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

Concernant la définition d'une méthode after_initialize, il pourrait y avoir des problèmes de performances car after_initialize est également appelé par chaque objet retourné par: find: http://guides.rubyonrails.org/active_record_validations_callbacks.html#after_initialize-and-after_find

Si la colonne se trouve être une colonne de type «état» et que votre modèle se prête à l'utilisation de machines à états, envisagez d'utiliser la gemme aasm , après quoi vous pouvez simplement faire

  aasm column: "status" do
    state :available, initial: true
    state :used
    # transitions
  end

Il initn'initialise toujours pas la valeur des enregistrements non enregistrés, mais c'est un peu plus propre que de rouler le vôtre avec ou autre chose, et vous récoltez les autres avantages d'un aasm tels que les étendues pour tous vos statuts.

https://github.com/keithrowell/rails_default_value

class Task < ActiveRecord::Base
  default :status => 'active'
end

Je suggère fortement d'utiliser le joyau "default_value_for": https://github.com/FooBarWidget/default_value_for

Il existe des scénarios délicats qui nécessitent à peu près la priorité sur la méthode d'initialisation, ce que fait ce joyau.

Exemples:

Votre valeur par défaut db est NULL, votre valeur par défaut définie par le modèle / ruby ​​est "une chaîne", mais vous voulez réellement définir la valeur sur nil pour une raison quelconque:MyModel.new(my_attr: nil)

La plupart des solutions ici ne parviendront pas à définir la valeur à zéro et la définiront par défaut.

OK, alors au lieu de prendre l' ||=approche, vous passez à my_attr_changed?...

MAIS imaginez maintenant que votre valeur par défaut db est "une chaîne", votre valeur par défaut définie par le modèle / ruby ​​est "une autre chaîne", mais dans un certain scénario, vous souhaitez définir la valeur sur "une chaîne" (la valeur par défaut db):MyModel.new(my_attr: 'some_string')

Cela se traduira par my_attr_changed?être faux car la valeur correspond à la valeur par défaut db, qui à son tour déclenchera votre code par défaut défini en rubis et définira la valeur sur "une autre chaîne" - encore une fois, pas ce que vous vouliez.

Pour ces raisons, je ne pense pas que cela puisse être accompli correctement avec juste un hook after_initialize.

Encore une fois, je pense que le joyau "default_value_for" adopte la bonne approche: https://github.com/FooBarWidget/default_value_for

Voici une solution que j'ai utilisée et qui m'a un peu surpris n'a pas encore été ajoutée.

Il y a deux parties. La première partie définit la valeur par défaut dans la migration réelle, et la deuxième partie ajoute une validation dans le modèle garantissant que la présence est vraie.

add_column :teams, :new_team_signature, :string, default: 'Welcome to the Team'

Vous verrez donc ici que la valeur par défaut est déjà définie. Maintenant, dans la validation, vous voulez vous assurer qu'il y a toujours une valeur pour la chaîne, alors faites simplement

 validates :new_team_signature, presence: true

Cela vous permet de définir la valeur par défaut pour vous. (pour moi, j'ai "Bienvenue dans l'équipe"), puis cela ira un peu plus loin et s'assurera qu'il y a toujours une valeur présente pour cet objet.

J'espère que cela pourra aider!

# 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

utiliser default_scope dans les rails 3

api doc

ActiveRecord masque la différence entre la définition par défaut définie dans la base de données (schéma) et la définition par défaut effectuée dans l'application (modèle). Lors de l'initialisation, il analyse le schéma de la base de données et note toutes les valeurs par défaut qui y sont spécifiées. Plus tard, lors de la création d'objets, il attribue les valeurs par défaut spécifiées au schéma sans toucher à la base de données.

discussion

Depuis les docs api http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html Utilisez la before_validationméthode dans votre modèle, elle vous donne les options de création d'une initialisation spécifique pour créer et mettre à jour des appels, par exemple dans cet exemple (encore une fois le code est pris à partir de l'exemple api docs) le champ numéro est initialisé pour une carte de crédit. Vous pouvez facilement l'adapter pour définir les valeurs que vous souhaitez

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

Surpris que son n'a pas été suggéré ici