¿Cómo puedo establecer valores predeterminados en ActiveRecord?

Ponemos los valores predeterminados en la base de datos a través de migraciones (especificando la opción :default en cada definición de columna) y dejamos que Active Record use estos valores para establecer el valor predeterminado para cada atributo.

En mi humilde opinión, este enfoque está alineado con los principios de AR : convención sobre configuración, SECO, la definición de tabla conduce el modelo, no al revés.

Tenga en cuenta que los valores predeterminados todavía están en el código de la aplicación (Ruby), aunque no en el modelo, sino en el migración(s).

Algunos casos simples se pueden manejar definiendo un valor predeterminado en el esquema de la base de datos, pero que no maneja un número de casos más complicados, incluidos los valores calculados y las claves de otros modelos. Para estos casos hago esto:

after_initialize :defaults

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

He decidido usar after_initialize pero no quiero que se aplique a objetos que se encuentran solo aquellos nuevos o creados. Creo que es casi impactante que no se proporcione una devolución de llamada after_new para este caso de uso obvio, pero lo he hecho confirmando si el objeto ya está persistido indicando que no es nuevo.

Habiendo visto la respuesta de Brad Murray, esto es aún más limpio si la condición se mueve a la solicitud de devolución de llamada:

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

En Rails 5+, puede usar el método attribute dentro de sus modelos, por ejemplo.:

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

El patrón de devolución de llamada after_initialize se puede mejorar simplemente haciendo lo siguiente

after_initialize :some_method_goes_here, :if => :new_record?

Esto tiene un beneficio no trivial si su código init necesita tratar con asociaciones, ya que el siguiente código desencadena un sutil n+1 si lee el registro inicial sin incluir el asociado.

class Account

  has_one :config
  after_initialize :init_config

  def init_config
    self.config ||= build_config
  end

end

Los chicos de Phusion tienen un buen plugin para esto.

Una manera potencial aún mejor / más limpia que las respuestas propuestas es sobrescribir el accessor, así:

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

Vea "Sobrescribir los accesos predeterminados" en la documentación ActiveRecord::Basey más de StackOverflow sobre el uso de self.

Utilizo el attribute-defaults gem

De la documentación: ejecute sudo gem install attribute-defaults y agregue require 'attribute_defaults' a su aplicación.

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"

Preguntas similares, pero todas tienen un contexto ligeramente diferente: - ¿Cómo puedo crear un valor predeterminado para los atributos en el modelo de Rails activerecord?

Mejor Respuesta: Depende de Lo Que Quieras!

Si quieres que cada objeto comience con un valor: use after_initialize :init

¿Desea que el formulario new.html tenga un valor predeterminado al abrir la página? 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 

Si quieres cada objeto a tener un valor calculado a partir de la entrada del usuario: use before_save :default_values ¿Desea que el usuario ingrese X y luego Y = X+'foo'? uso:

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

¡Para esto están los constructores! Sobreescriba el método initialize del modelo.

Utilice el método after_initialize.

Chicos Sup, terminé haciendo lo siguiente:

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

Funciona como un encanto!

Lo primero es lo primero: No estoy en desacuerdo con la respuesta de Jeff. Tiene sentido cuando su aplicación es pequeña y su lógica simple. Estoy aquí tratando de dar una idea de cómo puede ser un problema al construir y mantener una aplicación más grande. No recomiendo usar este enfoque primero al construir algo pequeño, sino tenerlo en cuenta como un enfoque alternativo:

Una pregunta aquí es si este valor predeterminado en los registros es lógica de negocio. Si lo es, sería prudente ponerlo en el modelo OR. Dado que el campo que menciona ryw es active , esto suena como lógica de negocios. Por ejemplo, el usuario está activo.

¿Por qué tendría que ser cauteloso al poner las preocupaciones comerciales en un modelo OR?

1. Rompe SRP. Cualquier clase heredada de ActiveRecord:: Base ya está haciendo un lote de diferentes cosas, la principal de ellas es la consistencia de datos (validaciones) y la persistencia (guardar). Poniendo la lógica de negocios, por pequeña que sea, en AR:: Base rompe SRP.

2. Es más lento para probar. Si quiero probar cualquier forma de lógica que ocurra en mi modelo OR, mis pruebas tienen que inicializar Rails para poder ejecutarse. Esto no será demasiado de un problema en el comienzo de su aplicación, pero se acumulará hasta que sus pruebas unitarias tardan mucho tiempo en ejecutarse.

3. Se romperá SRP aún más en la línea, y de maneras concretas. Digamos que nuestro negocio ahora requiere que enviemos correos electrónicos a los usuarios cuando el Elemento se active. Ahora estamos agregando envíe por correo electrónico la lógica al modelo Item OR, cuya responsabilidad principal es modelar un Elemento. No debe preocuparse por la lógica del correo electrónico. Este es un caso de efectos secundarios comerciales. Estos no pertenecen al modelo OR.

4. Es difícil diversificar. He visto aplicaciones Rails maduras con cosas como un campo init_type: string respaldado por una base de datos, cuyo único propósito es controlar la lógica de inicialización. Esto está contaminando la base de datos para solucionar un problema estructural. Hay mejores maneras, yo creer.

La forma de PORO: Si bien esto es un poco más de código, le permite mantener sus Modelos OR y la Lógica de Negocio separados. El código aquí está simplificado, pero debería mostrar la idea:

class SellableItemFactory
  def self.new(attributes = {})
    record = Item.new(attributes)
    record.active = true if record.active.nil?
    record
  end
end

Entonces con esto en su lugar, la forma de crear un nuevo elemento sería

SellableItemFactory.new

Y mis pruebas ahora podrían simplemente verificar que ItemFactory se establece activo en Item si no tiene un valor. No se necesita inicialización de rieles, no se rompe SRP. Cuando la inicialización del elemento se convierte en más avanzado (por ejemplo, establecer un campo de estado, un tipo predeterminado, etc.) la ItemFactory puede tener esto añadido. Si terminamos con dos tipos de valores predeterminados, podemos crear un nuevo BusinesCaseItemFactory para hacer esto.

NOTA: También podría ser beneficioso usar la inyección de dependencias aquí para permitir que la fábrica construya muchas cosas activas, pero lo dejé fuera por simplicidad. Aquí está: yo.nuevo (klass = Elemento, atributos = {})

Esto ha sido respondido durante mucho tiempo, pero necesito valores predeterminados con frecuencia y prefiero no ponerlos en la base de datos. Creo una preocupación DefaultValues:

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

Y luego usarlo en mis modelos como así:

class Widget < ApplicationRecord
  include DefaultValues

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

También he visto a la gente ponerlo en su migración, pero prefiero verlo definido en el código del modelo.

¿Hay una forma canónica de establecer el valor predeterminado para los campos en Modelo ActiveRecord?

La forma canónica de Rails, antes de Rails 5, era en realidad establecerla en la migración, y simplemente mirar en el db/schema.rb para siempre que quiera ver qué valores predeterminados están siendo establecidos por la base de datos para cualquier modelo.

Contrario a lo que dice la respuesta de @Jeff Perrin (que es un poco old), el enfoque de migración incluso aplicará el predeterminado cuando se usa Model.new, debido a algunos Rails magic. Trabajo verificado en Rails 4.1.16.

Lo más simple es a menudo lo mejor. Menos deuda de conocimiento y posibles puntos de confusión en el código base. Y 'simplemente funciona'.

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

El null: false no permite valores NULOS en la BD, y, como un beneficio adicional, también actualiza todos los registros de BD preexistentes se establece con el valor predeterminado para este campo también. Puede excluir este parámetro en el migración si lo desea, pero me pareció muy útil!

La forma canónica en Rails 5 + es, como dijo @Lucas Caton:

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

El problema con las soluciones after_initialize es que debe agregar un after_initialize a cada objeto que busque en la base de datos, independientemente de si accede a este atributo o no. Sugiero un enfoque perezoso.

Los métodos de atributo (getters) son, por supuesto, métodos en sí mismos, por lo que puede sobrescribirlos y proporcionar un valor predeterminado. Algo como:

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

A menos que, como alguien señaló, necesitas hacer Foo.find_by_status ('ACTIVO'). En ese caso creo realmente necesitaría establecer las restricciones predeterminadas en su base de datos, si la base de datos lo admite.

Me encontré con problemas con after_initialize dando ActiveModel::MissingAttributeError errores al hacer hallazgos complejos:

Eg:

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

"buscar" en el .where es hash de condiciones

Así que terminé haciéndolo sobrescribiendo initialize de esta manera:

def initialize
  super
  default_values
end

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

La llamada super es necesaria para asegurarse de que el objeto se inicializa correctamente desde ActiveRecord::Base antes de hacer mi código personalizado, es decir: default_values

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

  before_save{ self.status ||= ACTIVE }
end

Recomiendo encarecidamente usar la gema" default_value_for": https://github.com/FooBarWidget/default_value_for

Hay algunos escenarios complicados que requieren reemplazar el método initialize, lo que hace esa gema.

Ejemplos:

El valor predeterminado de la base de datos es NULL, el valor predeterminado definido por model / ruby es "some string", pero en realidad desea establecer el valor en nil por cualquier razón: MyModel.new(my_attr: nil)

La mayoría de las soluciones aquí fallarán al establecer el valor a nil, y en su lugar establecer el valor predeterminado.

OK, entonces en lugar de tomar el enfoque ||=, cambias a my_attr_changed?...

PERO ahora imagine que en su db predeterminado es "una cadena", su modelo/ruby-definido por defecto es "otra cadena", pero por debajo de un determinado escenario, desea para establecer el valor a "cadena" (la base de datos predeterminada): MyModel.new(my_attr: 'some_string')

Esto dará como resultado que my_attr_changed? sea false porque el valor coincide con el valor predeterminado de la base de datos, lo que a su vez disparará su código predeterminado definido por ruby y establezca el valor en "some other string" again de nuevo, no es lo que desea.

Por esas razones, no creo que esto se pueda lograr correctamente con solo un hook after_initialize.

Nuevamente, creo que la gema" default_value_for " está tomando el enfoque correcto: https://github.com/FooBarWidget/default_value_for

Aunque hacer eso para establecer valores predeterminados es confuso y incómodo en la mayoría de los casos, también puede usar :default_scope. Echa un vistazo comentario de squil aquí.

El método After_initialize está obsoleto, use la devolución de llamada en su lugar.

after_initialize :defaults

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

Sin embargo, usar : default en tus migraciones sigue siendo la forma más limpia.

He encontrado que el uso de un método de validación proporciona mucho control sobre la configuración de valores predeterminados. Incluso puede establecer valores predeterminados (o validación de error) para las actualizaciones. Incluso puede establecer un valor predeterminado diferente para insertos vs actualizaciones si realmente lo desea. Tenga en cuenta que el valor predeterminado no se establecerá hasta # valid? se llama.

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

Con respecto a la definición de un método after_initialize, podría haber problemas de rendimiento porque after_initialize también es llamado por cada objeto devuelto por: find : http://guides.rubyonrails.org/active_record_validations_callbacks.html#after_initialize-and-after_find

Si la columna resulta ser una columna de tipo 'status', y su modelo se presta al uso de máquinas de estado, considere usar la gema aasm, después de lo cual simplemente puede hacer

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

Todavía no inicializa el valor para los registros no guardados, pero es un poco más limpio que rodar el tuyo con init o lo que sea, y cosechas los otros beneficios de aasm, como los ámbitos para todos tus estados.

Https://github.com/keithrowell/rails_default_value

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

Usar default_scope en rails 3

Api doc

ActiveRecord oculta la diferencia entre el valor predeterminado definido en la base de datos (esquema) y el valor predeterminado realizado en la aplicación (modelo). Durante la inicialización, analiza el esquema de la base de datos y toma nota de los valores predeterminados especificados allí. Más tarde, al crear objetos, asigna esos valores predeterminados especificados en el esquema sin tocar la base de datos.

Discusión

Desde la api docs http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html Utilice el método before_validation en su modelo, que le da las opciones de crear inicialización específica para crear y actualizar llamadas por ejemplo, en este ejemplo (de nuevo código tomado del ejemplo de api docs) el campo de número se inicializa para una tarjeta de crédito. Puede adaptar esto fácilmente para establecer los valores que desee

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

Sorprendido de que su no se ha sugerido aquí