Skip to content

schema.sql aplica tres migraciones sobre clan_members antes de crear la tabla #82

Description

@leocagli

El CI que entró con el #31 y el #81 corre psql -f schema.sql sobre una base limpia. Ahí se ve esto:

psql:schema.sql:122: ERROR:  relation "clan_members" does not exist
LINE 3:     FROM clan_members cm
psql:schema.sql:138: ERROR:  relation "clan_members" does not exist
LINE 3:     FROM clan_members cm

El problema

En api/schema.sql el orden está invertido:

Línea Qué hace
109 SELECT ... FROM clan_members cm dentro de un CTE que alimenta un UPDATE characters
126 el mismo CTE, alimentando un DELETE FROM clan_members
135 DELETE FROM clan_members cm USING incompatible_members im
147 CREATE TABLE IF NOT EXISTS clan_members (...)

Las tres migraciones de datos corren antes de que exista la tabla.

Por qué importa

psql corre sin ON_ERROR_STOP, así que no aborta: reporta el error y sigue con la siguiente sentencia. El resultado es que el schema queda casi completo y las tres migraciones no se aplican nunca, en silencio.

Esas migraciones existen para expulsar de un clan a los personajes cuya facción es incompatible con la alineación del clan. Sobre una base nueva no hay datos que migrar, así que no se nota. Sobre una base que ya tiene miembros, el efecto es que quedan miembros incompatibles adentro y nadie se entera, porque el error se imprimió hace 500 líneas.

Qué hay que hacer

  • Mover el bloque CREATE TABLE IF NOT EXISTS clan_members (línea 147) y sus ALTER TABLE e índices asociados por encima de la primera sentencia que usa la tabla.
  • Revisar el resto del archivo con el mismo criterio: buscar cualquier otra sentencia que referencie una tabla creada más abajo. Con 629 líneas es probable que esta no sea la única.
  • Agregar \set ON_ERROR_STOP on al principio de schema.sql, o pasar -v ON_ERROR_STOP=1 en el paso de CI. Sin eso, el próximo error de orden vuelve a pasar desapercibido.

Criterios de aceptación

  • psql -f schema.sql sobre una base vacía termina sin una sola línea ERROR:.
  • Con ON_ERROR_STOP activo, el script corre de punta a punta y sale con código 0.
  • Correr schema.sql dos veces seguidas sobre la misma base sigue siendo idempotente, que es lo que hoy garantizan los IF NOT EXISTS.
  • Las tres migraciones de clan_members se aplican de verdad: un test que inserte un miembro incompatible antes de correr el schema y verifique que quedó expulsado.
  • El job API del CI pasa el paso Run migrations / schema sin errores en el log.

Evidencia que suma

  • Salida de psql -f schema.sql sobre una base limpia, pegada como bloque de código, mostrando cero ERROR:.
  • Captura o salida del run del CI en verde para ese paso.

Fuera de alcance

  • Migrar a una herramienta de migraciones versionadas. Es una discusión aparte y más grande.
  • Cambiar la lógica de compatibilidad entre facción y alineación. Sólo se trata de que corra.

Por dónde empezar

api/schema.sql, líneas 105 a 175. El bloque de clan_members está completo entre la 147 y la 174, incluyendo sus constraints e índices: es un movimiento en bloque, no una reescritura.

Estimación

Entre 2 y 4 horas. Nivel inicial a intermedio en SQL. Lo que lleva tiempo no es mover el bloque, es auditar las 629 líneas buscando el resto de los casos.

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardThird CampaignCampaign: Third CampaignbugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions