yeta1990/ft_transcendence

Postgres

Opened this issue · 1 comments

yeta1990 commented

Documentación general:

Documentación del entorno de desarrollo de ft_containers de postgres:

  • Basta con hacer make o docker-compose up en la raíz para levantar todos los contenedores
  • Sobre la base de datos a utilizar: dentro de la instancia del servidor postgres, se pueden crear distintas bases de datos, que a su vez tendrán distintas tablas. La base de datos que viene por defecto (y vacía) es 'posgresql'. Por simplificar el mantenimiento del entorno de desarrollo mi recomendación es que utilicemos esa.
  • Hay dos scripts relacionados con el mantenimiento de la base de datos, explicación en el siguiente punto.
  • Es posible que en linux haya problemas de persistencia del contenedor, avisad a @yeta1990 si lo probáis en Linux y tenéis algo chungo.

Scripts de mantenimiento de postgres

  • scripts/exportDB.sh: se ejecuta para hacer un backup de la base de datos. En el menú, basta con elegir la opción 1, que exporta el contenido de 'postgres' (la base de datos creada por defecto por el servidor -comentado un poco más arriba-).
  • scripts/restoreDB.sh: borra la base de datos 'postgres' del contenedor, la vuelve a crear vacía, e importa el último archivo .sql que se haya creado en la carpeta desde donde se ejecuta el script.

Otras utilidades postgres

  • Para hacer querys directamente sobre la base de datos, una vez estamos conectados dentro del contenedor: psql -U postgres
  • \l lista las bases de datos que hay
  • docker exec -it tx_postgres psql -U postgres -W postgres Conectarse al contenedor de la base de datos, directamente a la base de datos llamada "postgres" (la que usamos).
  • \d user lista el esquema de la tabla user
  • dentro de psql, si queremos comprobar que se han creado unos datos, ojo que hay que poner el prefijo "public" (el esquema) en la tabla SELECT * from public.user; he estado investigando y no termino de tener claro por qué no coge por defecto el schema public, a lo mejor es porque tengo otra tabla user creada a mano y no soy capaz de distinguirlas, who knows.
  • sintaxis para insertar a mano (ojo con las comillas, son vitales): INSERT INTO room (name, "hasPass", "password", "ownerId") values ('#asdf', 'f', '', 5);
  • sintaxis para vaciar una tabla y todas sus relaciones donde aparezca info: TRUNCATE [nombre de la tabla] CASCADE;
  • borrar una tabla: DROP TABLE [nombre de la tabla];

Conector/ORM Typeorm

jjcarretero commented

Migraciones

El concepto de migración se refiere a la capacidad de realizar cambios en la estructura de la base de datos de forma incremental, en lugar de hacer cambios directamente en la base de datos en sí. Esto permite mantener un historial de los cambios realizados, lo cual es útil para controlar versiones, colaborar con otros desarrolladores y revertir cambios si es necesario.

Las migraciones tienen varias utilidades:

  • Control de versiones: Las migraciones permiten mantener un registro de los cambios realizados en la estructura de la base de datos a lo largo del tiempo. Esto facilita el seguimiento de los cambios realizados en diferentes versiones de la aplicación y brinda la posibilidad de volver a versiones anteriores si es necesario.

  • Colaboración en equipo: Al utilizar migraciones, varios desarrolladores pueden trabajar en paralelo en diferentes cambios de la base de datos sin interferir entre sí. Cada desarrollador puede crear y aplicar sus propias migraciones sin afectar el trabajo de otros miembros del equipo.

  • Mantenimiento y despliegue: Las migraciones facilitan el mantenimiento y despliegue de la aplicación en diferentes entornos. Al tener un registro de los cambios en la base de datos, es más sencillo aplicar esos cambios en diferentes instancias de la base de datos, ya sea en desarrollo, pruebas o producción.

  • Reversión de cambios: En caso de que un cambio en la estructura de la base de datos tenga un efecto no deseado o cause problemas, las migraciones permiten revertir esos cambios de manera controlada. Esto evita la pérdida de datos y facilita la recuperación de la base de datos a un estado anterior.

Es recomendable implementar migraciones en proyectos que utilizan bases de datos Postgres, TypeORM y NestJS debido a las ventajas mencionadas anteriormente. Esto promueve una gestión más eficiente de la base de datos, facilita el trabajo en equipo y mejora el control sobre los cambios realizados en la estructura de la base de datos a lo largo del ciclo de vida del proyecto.

Comandos para migrar:

  • npm run typeorm:generate-migration --name=<nombre_que_queramos>

Para recuperar una migracion:

  • Cambiar el archivo typeOrm.config.ts:
import { DataSource } from 'typeorm';
import { ConfigService } from '@nestjs/config';
import { config } from 'dotenv';
import PostEntity from './src/posts/post.entity';
import { CreatePost1658694616973 } from './migrations/1658694616973-CreatePost';
 
config();
 
const configService = new ConfigService();
 
export default new DataSource({
  type: 'postgres',
  host: configService.get('POSTGRES_HOST'),
  port: configService.get('POSTGRES_PORT'),
  username: configService.get('POSTGRES_USER'),
  password: configService.get('POSTGRES_PASSWORD'),
  database: configService.get('POSTGRES_DB'),
  entities: [PostEntity],
  migrations: [CreatePost1658694616973],
});