Ejecución y gestión de migraciones con Time1M en Node.js

Clase 16 de 36 • Curso de NestJS: Persistencia de Datos con TypeORM

Resumen

¿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?

Run (ejectuar migración): Para aplicar una nueva migración y asegurarse de que está registrada en el control de migraciones.
Show (mostrar migraciones): Para listar las migraciones que se han ejecutado hasta el momento.
Drop (borrar datos): Un comando delicado que elimina todas las tablas y datos; debe usarse con precaución.

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:

Abre el pgAdmin y localiza la tabla products.
Elimina la tabla si ya existe para evitar conflictos de duplicado.
Borra también la tabla 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:

Verifica que la tabla migrations está actualizada.
Asegúrate de que la nueva estructura y los datos de la tabla 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!

Eduardo Pech

student•

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

Walter Lensinas

student•

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

Walter Lensinas

student•

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.

Ricardo Tribaldos Hernández

student•

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"
# ...

Renato Renzo Luna Herrera

student•

Alguien mas en vez de drop puso hakai? xD

Andrés Esteban Rodríguez Jiménez

student•

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.

Emil Zapata

student•

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"

brandon james grimaldo moscote

student•

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

student•

¿Y para correr las migraciones en producción una vez realizado el deploy como se lo haría?

Andres Prieto

student•

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

student•

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...