ruby on rails - Usando attr_accessor y attr_accessible en el mismo campo

ruby-on-rails field

Question

¿Qué sucede en el fondo con el siguiente código?

class User < ActiveRecord::Base

 attr_accessor :name
 attr_accessible :name

end

Sugerencia: Al crear una instancia de la clase, ¿se mantendrá en la base de datos? ¿Por qué o por qué no?

Answer 1

Como hereda ActiveRecord , se mantendrá cuando llame al método save (pero no cuando se crea una instancia).

Si no tiene ningún atributo para ese modelo, supongo que ActiveRecord simplemente guardará una nueva fila en la base de datos (es decir, su objeto solo tendrá una id persistente). Esto tiene sentido, ya que más tarde puede agregar atributos a su modelo de User , y las instancias persistentes aún se pueden recuperar.

Answer 2

En la mayoría de los casos, no necesita usar attr_accessor si el campo es una columna en la tabla de users en su base de datos. ActiveRecord lo resolverá por ti.

attr_accessible simplemente permite que el campo se asigne mediante asignación masiva (por ejemplo, con update_attributes ). Esto es bueno por motivos de seguridad. Más información de los documentos de la API de MassAssignmentSecurity .

Answer 3

attr_accessor es código ruby ​​y se usa cuando no tiene una columna en su base de datos, pero aún desea mostrar un campo en sus formularios. La única forma de permitir esto es attr_accessor :fieldname y puede usar este campo en su Vista, o modelo, si lo desea, pero principalmente en su Vista.

attr_accessible le permite listar todas las columnas que desea permitir la Asignación masiva, como andy eludido anteriormente. Lo opuesto a esto está attr_protected, lo que significa que NO quiero que a nadie se le permita Mass Assign to this. Más probable es que sea un campo en su base de datos con el que no quiere que nadie mordique. Como un campo de estado, o similar.

Answer 4

Gracias a todos por las respuestas rápidas! Sus respuestas combinadas me dieron las piezas que necesitaba para entender este rompecabezas, creo.

(En un problema relacionado, recibía muchos errores nulos como "El objeto no admite #inspect" y "método indefinido ''claves'' para nil: NilClass". Pude resolverlo ahora, eliminando el campo att_accessor en total.)

Al experimentar con este caso particular, esto es lo que descubrí:

En realidad, el campo: nombre no se mantendrá en la base de datos.

user = User.new(:name=>"somename")

Solo establecerá el atributo en el objeto, pero no persistirá la columna: name en la base de datos. Al igual que la siguiente salida de ''consola de rieles'' muestra:

> user
=> <User id: nil, created_at: nil, updated_at: nil>
> user.save
=> true
> user
=> <User id:1, created_at: 2011-01-19 12:37:21, updated_at: 2011-01-19 12:37:21>

Supongo que esto se debe a que * el setter creado por attr_accessor anulará el setter * de ActiveRecord (que se ocupa de la persistencia de la base de datos). Sin embargo, aún puede recuperar el valor del campo: nombre del objeto, como este:

> user.name
=> "somename"

Entonces, en conclusión, aprendí que usar attr_accessor en los campos podría hacer que no se persistan en la base de datos. Y aunque pensé que attr_accessible describe los campos en la base de datos que deberían ser accesibles desde el exterior, no parece marcar la diferencia en este caso.