Renato Renzo Luna Herrera
Alguien mas en vez de drop puso hakai? xD
¿Cómo ejecutar una migración correctamente?
Generar una migración en un proyecto es solo el primer paso. Para aplicar estos cambios a nuestra base de datos, debemos ejecutar la migración y llevar un control de cuáles ya han sido aplicadas. Este proceso es esencial para mantener la integridad de nuestra estructura de datos y asegurar que todos los cambios se incorporen de forma eficiente.
¿Cómo configurar npm para ejecutar migraciones?
Para gestionar efectivamente las migraciones en un proyecto usando Time1M y npm, primero debemos añadir nuevas tareas en nuestro archivo package.json. Estas tareas nos permitirán correr migraciones y monitorear cuáles se han ejecutado.
Ejemplo de comandos a añadir en package.json:
"scripts": { "migrations:run": "npx time1m run", "migrations:show": "npx time1m show", "migrations:drop": "npx time1m drop" }
¿Qué tareas se deben agregar?
Para ejecutar la migración simplemente debemos correr el comando desde la terminal:
npm run migrations:run
¿Qué hacer si encuentras errores en la ejecución?
Como es común en la programación, puedes encontrar errores al intentar correr una migración. Si, al ejecutar el comando para correr migraciones, aparece un mensaje de error diciendo que la tabla ya existe, debemos revisar la configuración de nuestro proyecto.
Un posible ajuste es desactivar el modo síncrono si todavía está activado. Esto se hace ajustando la configuración para que el sincronismo se maneje a través de migraciones:
// Configuración del modo síncrono desactivado sincronizar: false
Además, es posible que debamos usar herramientas adicionales, como pgAdmin, para borrar manualmente tablas existentes, permitiendo que la migración corra sin conflictos.
Usar pgAdmin para gestionar tablas
Al gestionar bases de datos, herramientas GUI como pgAdmin permiten una mayor visibilidad y control. Si necesitamos eliminar tablas previas manualmente, pgAdmin simplifica este proceso:
pgAdmin y localiza la tabla products.migrations si así lo deseas para un nuevo comienzo limpio.¿Cómo verificar migraciones exitosas?
Una vez que la migración se haya corrido sin errores podemos verificar que sus resultados sean correctos. Usando pgAdmin, podemos refrescar nuestras tablas y comprobar si los datos se han registrado correctamente:
migrations está actualizada.products coinciden con la especificación de la migración.Finalmente, recuerda que cualquier cambio en los datos debe ser realizado de forma pausada y con control de versiones para mantener la integridad de la base de datos. Sigue explorando y experimentando con comandos adicionales que puedes aplicar consultando la documentación de Time1M. ¡Sigue adelante aprendiendo y perfeccionando tus habilidades en la gestión de bases de datos!
Lo que vimos fue:
package.json
"scripts": { "migrations:generate": "npm run typeorm -- migration:generate -n", "migrations:run": "npm run typeorm -- migration:run", "migrations:show": "npm run typeorm -- migration:show", "migrations:drop": "npm run typeorm -- migration:drop" },
database.module.ts
imports: [ TypeOrmModule.forRootAsync({ inject: [config.KEY], useFactory: (configService: ConfigType<typeof config>) => { const { user, password, host, dbName, port } = configService.postgres; return { type: 'postgres', host, port, username: user, password, database: dbName, synchronize: false, autoLoadEntities: true, }; }, }), ],
Los comandos que utilisamos fueron:
Para crear la migration en la base de datos
npm run migrations:run
Para ver. quemigrations han sido creados
npm run migrations:run
Si le agregan el revert esta bueno experimentarlo, mas que nada para volver a atras los cambios en caso de que se haya detectado algun bug y tengas que salir a patchear la version que sacaste.
Agregas en el package.json
"migrations:revert": "npm run typeorm -- migration:revert"
Este el output:
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = current_schema() AND "table_name" = 'migrations' query: SELECT * FROM "migrations" "migrations" ORDER BY "id" DESC 1 migrations are already loaded in the database. init1621883836551 is the last executed migration. It was executed on Mon May 24 2021 16:17:16 GMT-0300 (Argentina Standard Time). Now reverting it... query: START TRANSACTION query: DROP TABLE "user" query: DROP TABLE "customer" query: DROP TABLE "product" query: DROP TABLE "category" query: DROP TABLE "brand" query: DELETE FROM "migrations" WHERE "timestamp" = $1 AND "name" = $2 -- PARAMETERS: [1621883836551,"init1621883836551"] Migration init1621883836551 has been reverted successfully. query: COMMIT
en el caso del script del drop, se dropea el schema no la migracion, por lo que tendrian que cambiarlo. Borra todo dentro de la base.
"migrations:drop": "npm run typeorm -- schema:drop",
output
query: START TRANSACTION query: SELECT 'DROP VIEW IF EXISTS "' || schemaname || '"."' || viewname || '" CASCADE;' as "query" FROM "pg_views" WHERE "schemaname" IN (current_schema()) AND "viewname" NOT IN ('geography_columns', 'geometry_columns', 'raster_columns', 'raster_overviews') query: SELECT 'DROP TABLE IF EXISTS "' || schemaname || '"."' || tablename || '" CASCADE;' as "query" FROM "pg_tables" WHERE "schemaname" IN (current_schema()) AND "tablename" NOT IN ('spatial_ref_sys') query: DROP TABLE IF EXISTS "public"."migrations" CASCADE; query: DROP TABLE IF EXISTS "public"."brand" CASCADE; query: DROP TABLE IF EXISTS "public"."category" CASCADE; query: DROP TABLE IF EXISTS "public"."product" CASCADE; query: DROP TABLE IF EXISTS "public"."customer" CASCADE; query: DROP TABLE IF EXISTS "public"."user" CASCADE; query: SELECT 'DROP TYPE IF EXISTS "' || n.nspname || '"."' || t.typname || '" CASCADE;' as "query" FROM "pg_type" "t" INNER JOIN "pg_enum" "e" ON "e"."enumtypid" = "t"."oid" INNER JOIN "pg_namespace" "n" ON "n"."oid" = "t"."typnamespace" WHERE "n"."nspname" IN (current_schema()) GROUP BY "n"."nspname", "t"."typname" query: COMMIT Database schema has been successfully dropped.
Y para volver a generar la base de datos, solo se tiene que ejecutar el run de la migracion.
Renato Renzo Luna Herrera
Alguien mas en vez de drop puso hakai? xD
Ricardo Tribaldos Hernández
Un tip para el script de generar migraciones: agreguen el argumento -p (pretty) para que los comandos SQL autogenerados en el archivo de migraciones tengan un formato multilínea más fácil de leer.
# package.json # ... scripts: # ... "migrations_generate": "npm run typeorm -- migration:generate -p -n" # ...
Andrés Esteban Rodríguez Jiménez
Vanessa Quiquia
brandon james grimaldo moscote
Tengo una duda, no hay una forma de que basándome en una base de datos ya creada y con sus datos y relaciones desde por ejemplo mysql, con algún comando este cree automáticamente todo el código de esa base de datos en nuestro proyecto? o siempre tendremos que hacer las tablas y entidades desde nuestro backend?
Jilson Pérez
¿Y para correr las migraciones en producción una vez realizado el deploy como se lo haría?
Andres Prieto
Mandas las migraciones y las aplicas igual, eso generalmentel o trackean en una carpeta aparte y simplemente las mandan a producción después de que testing mire que no explote nada
Yonathan Gutierrez
En esta versión, además del comando con el flag -d debemos indicar donde están las migraciones, además de crear el datasource para la conexión con la base de datos...
Corriendo migraciones
Es importante que al momento de correr migraciones tengamos desactivado el modo síncrono de nuestra base de datos:
src/database/database.module.ts:@Module({ imports: [ TypeOrmModule.forRootAsync({ inject: [config.KEY], useFactory: (configService: ConfigType<typeof config>) => { const { user, host, dbName, password, port } = configService.postgres; return { // ... synchronize: false, autoLoadEntities: true, }; }, }), ], exports: [TypeOrmModule], })
En caso de que tengas tus tablas creadas y no te permita ejecutar la migración, debes borrar las tablas.
Ahora, para correr las migraciones solo debemos añadir los siguientes scripts en nuestro **package.json**:
{ "scripts": { // correr la última migración creada "migration:run": "npm run typeorm migration:run", // muestra las migraciones ejecutadas anteriormente "migration:show": "npm run typeorm migration:show", // borra TODAS lAS TABLAS (Peligroso) "migration:drop": "npm run typeorm migration:drop", // Revierte la última migración hecha "migration:revert": "npm run typeorm migration:revert", }, }
Para correr estos comandos, recordemos que tenemos que correr el comando:
npm run <script>
Y listo, así es como corremos migraciones.
Configuración del data-source.ts:
import { ConfigService } from '@nestjs/config'; import { config } from 'dotenv'; import { DataSource, DataSourceOptions } from 'typeorm'; config(); const configService = new ConfigService(); export const dataSourceOptions: DataSourceOptions = { type: 'postgres', username: configService.get('POSTGRES_USER'), password: configService.get('POSTGRES_PASSWORD'), database: configService.get('POSTGRES_DB'), port: configService.get('POSTGRES_PORT'), host: configService.get('POSTGRES_HOST'), synchronize: false, logging: true, entities: ['src/**/*.entity.{ts,js}'], migrations: ['src/database/migrations/*.{ts,js}'], }; export const AppDataSource = new DataSource(dataSourceOptions);
Comandos:
"typeorm": "ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js -d ./src/database/data-source.ts", "m:g": "npm run typeorm migration:generate ./src/database/migrations/update", "m:run": "npm run typeorm -- migration:run", "m:show": "npm run typeorm -- migration:show", "m:revert": "npm run typeorm -- migration:revert"