En el entorno de desarrollo, manejar migraciones en la base de datos es sencillo, pero cuando se trata de producción, la situación se complica. Existen consideraciones críticas que debemos tener en cuenta para asegurar que nuestras migraciones se ejecuten sin problemas y no causen interrupciones en nuestros servicios. Este artículo aborda esos aspectos y provee recomendaciones prácticas para manejar las migraciones en producción de manera efectiva.
¿Qué problemas pueden surgir con los esquemas en migraciones?
Un error común al lidiar con las migraciones es usar un esquema global que pueda corromperse. Por ejemplo:
Inconsistencias en el esquema: Si se modifica un atributo o tabla en el esquema ya creado, crear una nueva migración o desplegar puede causar conflictos.
Problemas con migraciones repetitivas: Intentar correr una migración de una columna ya existente puede generar errores, como el problema de 'role' mencionado en el texto.
¿Cuál es la importancia de una migración inicial adecuada?
Una migración inicial bien planteada es crucial al transitar al entorno de producción. Antes del primer release, se recomienda tener un esquema base que contemple toda la estructura de la base de datos:
Crea una migración inicial eficiente: Conten con todas las tablas y configuraciones básicas antes de lanzar el sistema en producción.
Evita la necesidad de iniar de cero: Una vez la base de datos está en producción, reiniciar sin datos de respaldo puede ser desastroso.
¿Cómo gestionar la versión del esquema para evitar corrupción?
Una práctica recomendada es separar el esquema de base de datos usado para el desarrollo del esquema de migración. Esto puede parecer contraintuitivo, dado que se repite código, pero garantiza que las migraciones se ejecuten de manera ordenada y exacta.
Repetir código en migraciones: Añadir manualmente los atributos sobre cada método de creación para asegurar que las migraciones reflejen fielmente la versión deseada.
No confiar completamente en esquemas globales: Puede ser que un esquema global no esté completamente versionado, por lo tanto, se debe tratar cada migración de manera única y específica.
¿Cómo solucionar errores comunes en migraciones?
Cuando se enfrentan problemas durante las migraciones, a menudo es necesario realizar un rollback o revert que puede eliminar migraciones o datos actuales. Sin embargo, esta operación es extremadamente delicada y debe realizarse con cautela para evitar pérdidas de datos:
Rollback para resolver errores de esquema: Si algún error es serio y solo hay datos de prueba, puede ser seguro realizar un rollback, pero asegúrate de tener copias de seguridad antes de intentarlo.
Identificar errores específicos: Lee los logs de errores y ajusta el esquema de migración para corregir problemas como atributos únicos que pueden estar causando conflictos.
Conclusión y desafío
Finalmente, al trabajar con migraciones para proyectos que están en producción, es esencial entender el flujo de cómo se crean, despliegan y gestionan dichas migraciones. Manejar cada migración con su propio esquema único versionado puede prevenir errores constantes y garantizar un sistema sólido y fiable en producción. Para cimentar este entendimiento, te desafío a crear una única migración que contenga toda la estructura inicial de tu base de datos, asegurando así un primer lanzamiento limpio y estructurado al entorno productivo.
Me carga el payaso... tengo más de 20 migraciones porque me puse a jugar con las tablas y las columnas en clases anteriores. Me tocó hacer una faena épica.
JAJAJAJAJA mis condolencias
Cuando ya estés montando producto; recuerda pasar tanto tiempo como sea posible, haciendo el modelo de la base de datos para correr el menor número de migraciones posibles; las migraciones son como pequeñas correcciones al modelo de base de datos, si ese modelo ya tiene todo no tendrías migraciones
Mi archivo único de migraciones es algo como esto:
que comandos usaste para crear estas migraciones en producción ?
A mi me dio error cuando puse el droptable de category antes del droptable de product... un error de que no se puede eliminar la tabla category porque otras tablas dependen de ella; lo cambié, puse el droptable de product primero y no me botó más error... no te pasó lo mismo?
Grande Nicolás! Te la comiste con este curso. Mil gracias, aprendí un montón!
este curso está 10/10 ☄
Las migraciones son muy delicadas, es por ello que se deben tener en cuenta los esquemas. A nivel producción no se recomienda crear migraciones paso a paso, más bien, crear una sola migración que ya tenga todas las relaciones y configuración por defecto.
Una buena practica es no repetir el código, pero en este caso se va necesitar repetir el esquema cuando se creen las tablas.
Cada vez que agregamos un atributo o algo parecido, lo mejor es no basarse en el esquema porque es algo genérico y no está versionado, sirve para el modelo, pero no es buena practica que sea la base de las migraciones porque lo configuramos en cualquier momento y puede dañar la configuración.
Los archivos que se cambiaron fueron los siguientes:
En mi opinión (para este caso) es mucho más sencillo borrar todas las migraciones y crear una sola en limpio con su respectivo código.
Con esto no habría ningún inconveniente al subirlo a producción. Claro, habría otras complicaciones más adelante en Development, pero si no tienen problema, pueden borrar y crear nuevamente las tablas de la base de datos.
Hola, a mi también me confunde mucho este tema. Se me ocurrió lo mismo que a ti sobre crear una sola migración pero ¿sabes que tipo de problemas o complicaciones pudiera causar esta solución a futuro?.
.
A ser sincero no se me ocurre nada que pueda tener complicación con ello pero si estoy mal corrigeme porfavor, siento que esto seria la mejor de las soluciones a esta gran confusión.
El inconveniente que tuve fue al desplegar en producción la aplicación, pues te arrojará error porque ya existen migraciones anteriores y difieren.
Podría.. 'solucionarse' enviando el comando de migrations:revert a Heroku y luego hacer el push con los cambios de las migraciones, peeeero creo que se borrarían las tablas existentes, así que no creo que sea buena idea alterar mucho las migraciones si ya tienes una aplicación funcionando en producción
Con este curso me he dado cuenta de que el Frontend es definitivamente más fácil que el Backend :sweat_smile:
Para mi lo contrario, el backend se me hizo más sencillo, o será que porque vengo de front-end se entiende mejor
Para solucionar el error de la migración que agrega la columna "role", ¿no hubiera sido más rápido sencillamente eliminar ese archivo de migración en el proyecto? luego haber hecho el commit y push respectivo para que producción no considere ese archivo.
Pense lo mismo xd,lo hize de esa manera funciono igual, al final era mas rapido de esa forma.
puede ser más rápido pero rompe con lo que tienen que ser las migraciones un histórico de las modificaciones a la base de datos básicamente estarías borrando la historia
Error ''VIRTUAL'
Con la configuración de ssl del video no me ha funcionado. Parece que para un pool si sirve poner:
dialectOptions:{ssl:{rejectUnauthorized:false}}
Pero me seguía dando un error de pg_hba.conf y ssl en off. He tenido que añadir:
Me seguía falando y encontré un aporte que indicaba que había que definir el modo:
heroku config:setPGSSLMODE=no-verify
Me salvaste con tu explicacion de verdad muchas gracias por tu aporte Raquel Iglesias De la Fuente
muchas gracias Raquel me sirvio demasiado!!!
Cuando ya se implementen los modelos en cada una de las migraciones, que debo hacer entonces con el schema de model.js?
Yo personalmente no he entendido nada de lo que hemos hecho durante el curso. Alguna recomendación sobre si debería de realizar algún curso en concreto antes de hacer este para poder seguirlo y entenderlo?
Me sirve cualquier fuente de información que me pueda ayudar a entender lo que explica el profesor
Hola Toni.
Sé qué en algunas oportunidades puede ser abrumador, ¿has realizado la ruta de base de datos desde 0? Yo creo que es un buen inicio para entender estos fundamentos. De igual manera te recomendaría escribir al team@platzi.com para que te ayuden a diseñar la ruta más ajustada a tí.
Yo creo que lo entendí porque ya tenía experiencia trabajando con mongo, mi recomendación sería que puedas intentar desarrollar cosas en este proyecto adicionales pero con los mismos temas, osea hacer ahora tu paginación tus propias relaciones y buscar tener esa experiencia de usar la capa de persistencia en otros proyectos.
Como Heroku ya no es free y ya no es una opción para tomar los cursos ¿podrían hacer un pequeño tutorial para poder subir nuestro proyecto por ejemplo a railway u otra plataforma? es muy dificil encontrar un video que nos ayude con este proyecto y la estructura que se ha creado, de verdad se les agradecería
Hola :
En el minuto 16:24 al revisar en insomnia me marca error al dar get products :
![](
Alguien me podria colaborar con el siguiente error ? Gracias
ERROR: getaddrinfo ENOTFOUNDundefined
Tambien pueden validar la existencia de la columna para no repetir codigo:
🦄✨Pueden probar mi api publicada en Render con este enlace :33
💚💚
Cristian no se puede ver
Porfin de verdad con este curso sufri mucho pero creo que valio la pena se siente tambien poder decir lo logre, gracias platzi , gracias al profesor fue muy claro ayudo un monton y austedes la comunidad cada vez que me encontraba un problea casi siempre habia alguien comentando al respecto y ayudo mucho la verdad.. a por mas si llegaste a leer esto es porque tu tambien lo lograste muchas felicidades para ti tambien.
Heroku no tienes planes gratuito a la fecha! hice mi deploy en render el repositorio de github
No me quedaré con la duda. Lo que entiendo es que las migraciones en la pratica nos servirán para que se creen todas las tablas en nuestra base de datos nueva. ¿Estoy bien en eso?
Si desde el inicio ya tengo claro como quiero que sea mi base de datos y no tengo que hacer fixes porque desde el inicio se lo que se iba a presentar. ¿Podría simplemente eliminar la creación de crear el rol puesto que si ya estaba en el esquema en la migración anterior se crearía?
No se si me hago entender, me gustaría salir de esa duda.
Si en eso tienes razón!
Los modelos de base de datos son espejos o representación de una tabla.
En la primera migración el Schema ya incluye "role".
Así que se crea la tabla con las propiedades que tiene el modelo en ese momento, si intentas agregar nuevamente columna con una migración. El motor de BD te arrojara una excepción.
De todas maneras investiga otros ORM y como se comportan las migraciones. En el caso de las migraciones se pueden trabajar algo diferente, como el caso Eloquent.
