Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Asignando un propietario a la tarea

24/36
Recursos

Aportes 7

Preguntas 6

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

¿Cuál es la forma sugerida de correr la migración sin perder los registros?

Normalmente, para agregar un campo que no quiero que pueda ser nulo a una tabla existente, agrego la columna sin el not null constraint y después de que ya la agregué a la tabla, agrego el constraint.

Pero para este caso, el foreign key constraint haría que Postgres me de otro error porque espera que forzosamente todos los valores de la columna para todos los registros sea valido, pero al estar llena de nulls, no nos dejará terminar la migración.

Algo que se me había ocurrido era poner un default = 0 pero al momento de agregar el constraint de la foreign key, seguro explotará.

El objetivo de esta clase es hacer una migración manual para enlazar la llave foránea de la tarea junto con la asignación del usuario.


Para comenzar hay que generar una migración con el comando rails g migration, este comando es útil porque los modelos se siguen actualizando, así que cada vez que se quiera hacer una actualización o modificar una estructura de la base de datos hay que hacer una migración.

Esta migración tiene el objetivo de añadir un propietario a una tarea por lo que le daremos el nombre AddOwnerToTask y le añadiremos la referencia del usuario con user:references.

El comando completo sería: rails g migration AddOwnerToTask user:references. Esto generará una nueva migración en la carpeta db>migrate.

En el archivo de migración se encuentra el método add_reference, que recibe la tabla a la cuál se va a relacionar, el nombre de la relación que se usará internamente y la llave foránea, el tercer parámetro indica que la relación no puede ser nula y el cuarto señala que se trata de una llave foránea.

add_reference :tasks, :user, null: false, foreign_key: true

Ahora, user no sería el mejor nombre para la relación entre la task y user, sería mejor llamarla owner, pero al cambiar el nombre de la relación también hay que indicarle a la llave foránea la tabla en la que debe buscar, ya que no existe ninguna tabla llamada owner. Además se la agregará un index para que tenga un mejor rendimiento.

add_reference :tasks, :owner, null: false, 
foreign_key: { to_table: :users}, index: true

Lo único que falta es añadir el campo al model de Task con el método belongs_to :owner, pero, como no existe el modelo owner también hay que indicarle explícitamente que se trata del model User.

belongs_to :owner, class_name: 'User'

Lo siguiente es ir al model de User y añadir la propiedad has_many :tasks.

Finalmente hay que ejecutar el comando rails db:migrate. Si existían registros de usuarios tendrán que ser eliminados para que se pueda ejecutar la migración. Se puede ejecutar el comando rails db:reset volver a la versión inicial de la base de datos, también se ejecutarán las migraciones de la carpeta db>migrate. Para hacer el reset hay que parar la ejecución del servidor.

Este es un shorcut

rails db:migrate:redo

Que buena clase, mucho que anotar y analizar ya que soy nuevo en este tema de rails. Muy bien explicado por parte del instructor, toca indagar un poquito sobre este tema para tener un conocimiento más amplio.

¿las tablas las modifica solamente en las bases de datos configuradas para el ambiente de desarrollo y test? ¿o también las de producción?

comando

rails g migration AddOwnerToTask user:references

Genial! Me interesó mucho el command rails db:reset