mtpk-postgres 0.1.2__tar.gz → 0.1.4__tar.gz

{mtpk_postgres-0.1.2 → mtpk_postgres-0.1.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mtpk_postgres
-Version: 0.1.2
+Version: 0.1.4
 Summary: Librería para sincronización estructural de bases de datos Postgres con modelos Python (adaptación de mtpk_mariadb)
 Author-email: José Jesús Andrés Zambrana <jjandres@multiplika.es>
 License: MIT
@@ -54,6 +54,26 @@ pip install -e .
 
 ## Historial
 
+- **0.1.4**: corrige la causa de fondo del bug de la 0.1.3, que solo tapaba el síntoma en la columna generada
+  en sí. Había dos problemas relacionados: (1) `comparar_generar_alter` comparaba el tipo de columna por su
+  nombre "en crudo" (`col.tipo`), así que un modelo que usa alias como `INT`, `TINYINT` o `DATETIME` (en vez de
+  `INTEGER`/`SMALLINT`/`TIMESTAMP`, que es como se reconstruyen siempre desde Postgres) nunca coincidía con la
+  realidad y proponía un `ALTER COLUMN ... TYPE` en cada ejecución aunque el tipo no hubiera cambiado — inofensivo
+  la mayoría de las veces (Postgres permite "cambiar" una columna a su mismo tipo), pero rechazado de plano si otra
+  columna `GENERATED` depende de la columna "alterada"; ahora se compara por el tipo canónico
+  (`Columna._tipo_base()`). (2) `ManagerDB.aplicar_cambios()` — la ruta que se usa en la primera sincronización de
+  una base de datos nueva — creaba todas las tablas del modelo y a continuación las volvía a comparar todas,
+  incluidas las que acababa de crear en la misma llamada; una tabla recién creada coincide por definición con el
+  modelo que la creó, así que ahora se excluye de esa comparación (que solo tiene sentido sobre tablas
+  preexistentes). Esta segunda corrección evita esta clase entera de falsos positivos, no solo el caso ya visto.
+- **0.1.3**: corrige un bug bloqueante en `comparar_generar_alter` — al crear una tabla nueva con una columna
+  `GENERATED ALWAYS AS (...) STORED` (p.ej. una columna de búsqueda `tsvector` calculada a partir de otra), la
+  siguiente pasada de comparación la trataba como una columna normal (la introspección no reconstruye la expresión
+  de generación) y proponía un `ALTER COLUMN` sobre ella justo después de crearla — algo que Postgres puede
+  rechazar cuando otras columnas dependen de la generada. Como `aplicar_cambios()` ejecuta todo en una única
+  transacción, ese fallo deshacía también la creación de las demás tablas. Ahora las columnas `generado` nunca se
+  comparan ni se alteran una vez existen (para cambiar su expresión hay que borrarlas y recrearlas a mano); de paso,
+  `Columna.to_sql()` ya respeta `not_null=True` en columnas generadas (antes se ignoraba).
 - **0.1.2**: soporte nativo para columnas `VECTOR(n)` (pgvector) e índices con método (`USING gin/hnsw/...`,
   `opclass`, `WITH (...)`) en `Index`. La introspección (`obtener_columnas_postgres`) ahora reconoce las columnas
   `vector` por su `udt_name` y reconstruye su dimensión leyendo el catálogo (`pg_attribute`/`format_type`); sin esto,

{mtpk_postgres-0.1.2 → mtpk_postgres-0.1.4}/README.md

@@ -34,6 +34,26 @@ pip install -e .
 
 ## Historial
 
+- **0.1.4**: corrige la causa de fondo del bug de la 0.1.3, que solo tapaba el síntoma en la columna generada
+  en sí. Había dos problemas relacionados: (1) `comparar_generar_alter` comparaba el tipo de columna por su
+  nombre "en crudo" (`col.tipo`), así que un modelo que usa alias como `INT`, `TINYINT` o `DATETIME` (en vez de
+  `INTEGER`/`SMALLINT`/`TIMESTAMP`, que es como se reconstruyen siempre desde Postgres) nunca coincidía con la
+  realidad y proponía un `ALTER COLUMN ... TYPE` en cada ejecución aunque el tipo no hubiera cambiado — inofensivo
+  la mayoría de las veces (Postgres permite "cambiar" una columna a su mismo tipo), pero rechazado de plano si otra
+  columna `GENERATED` depende de la columna "alterada"; ahora se compara por el tipo canónico
+  (`Columna._tipo_base()`). (2) `ManagerDB.aplicar_cambios()` — la ruta que se usa en la primera sincronización de
+  una base de datos nueva — creaba todas las tablas del modelo y a continuación las volvía a comparar todas,
+  incluidas las que acababa de crear en la misma llamada; una tabla recién creada coincide por definición con el
+  modelo que la creó, así que ahora se excluye de esa comparación (que solo tiene sentido sobre tablas
+  preexistentes). Esta segunda corrección evita esta clase entera de falsos positivos, no solo el caso ya visto.
+- **0.1.3**: corrige un bug bloqueante en `comparar_generar_alter` — al crear una tabla nueva con una columna
+  `GENERATED ALWAYS AS (...) STORED` (p.ej. una columna de búsqueda `tsvector` calculada a partir de otra), la
+  siguiente pasada de comparación la trataba como una columna normal (la introspección no reconstruye la expresión
+  de generación) y proponía un `ALTER COLUMN` sobre ella justo después de crearla — algo que Postgres puede
+  rechazar cuando otras columnas dependen de la generada. Como `aplicar_cambios()` ejecuta todo en una única
+  transacción, ese fallo deshacía también la creación de las demás tablas. Ahora las columnas `generado` nunca se
+  comparan ni se alteran una vez existen (para cambiar su expresión hay que borrarlas y recrearlas a mano); de paso,
+  `Columna.to_sql()` ya respeta `not_null=True` en columnas generadas (antes se ignoraba).
 - **0.1.2**: soporte nativo para columnas `VECTOR(n)` (pgvector) e índices con método (`USING gin/hnsw/...`,
   `opclass`, `WITH (...)`) en `Index`. La introspección (`obtener_columnas_postgres`) ahora reconoce las columnas
   `vector` por su `udt_name` y reconstruye su dimensión leyendo el catálogo (`pg_attribute`/`format_type`); sin esto,

{mtpk_postgres-0.1.2 → mtpk_postgres-0.1.4}/mtpk_postgres/__init__.py

@@ -1,4 +1,4 @@
-__version__ = "0.1.2"
+__version__ = "0.1.4"
 __author__ = "jjandres"
 
 from .interface import *

{mtpk_postgres-0.1.2 → mtpk_postgres-0.1.4}/mtpk_postgres/core_sync.py

@@ -129,14 +129,25 @@ class Columna:
     }
     _SIN_SOPORTE = {"GEOMETRY", "POINT", "LINESTRING", "POLYGON"}
 
-    def _tipo_sql(self) -> str:
-        """Traduce self.tipo (+ longitud/precision/escala) al tipo SQL de Postgres."""
+    def _tipo_base(self) -> str:
+        """
+        Nombre canónico del tipo en Postgres (sin longitud/precisión), p.ej. "INT" y "INTEGER"
+        devuelven ambos "INTEGER". Se usa tanto para generar SQL como para comparar el tipo del
+        modelo contra el tipo reconstruido desde la base de datos (obtener_columnas_postgres ya
+        siempre devuelve el nombre canónico) — comparar por el nombre "en crudo" haría que un
+        modelo que usa alias tipo "INT"/"TINYINT"/"DATETIME" nunca coincidiera con la realidad y
+        disparara un ALTER COLUMN de tipo en cada ejecución, aunque el tipo real no haya cambiado.
+        """
         tipo_upper = self.tipo.upper()
         if tipo_upper in self._SIN_SOPORTE:
             raise NotImplementedError(
                 f"El tipo '{tipo_upper}' requiere la extensión PostGIS y no está soportado."
             )
-        base = self._MAPA_TIPOS.get(tipo_upper, tipo_upper)
+        return self._MAPA_TIPOS.get(tipo_upper, tipo_upper)
+
+    def _tipo_sql(self) -> str:
+        """Traduce self.tipo (+ longitud/precision/escala) al tipo SQL de Postgres."""
+        base = self._tipo_base()
 
         if base == "VECTOR":
             if self.longitud is None:
@@ -166,6 +177,8 @@ class Columna:
 
         if self.generado:
             partes.append(f"{tipo_sql} GENERATED ALWAYS AS ({self.generado}) STORED")
+            if self.not_null:
+                partes.append("NOT NULL")
         else:
             partes.append(tipo_sql)
 
@@ -748,8 +761,14 @@ class Tabla:
             return (val_real, val_def) in equivalentes or (val_def, val_real) in equivalentes or val_real == val_def
 
         def tipos_iguales(col_real, col_def):
+            # Comparar por el tipo CANÓNICO (col._tipo_base()), no por el texto crudo de col.tipo:
+            # el modelo puede usar alias como "INT"/"TINYINT"/"DATETIME" que Postgres no distingue
+            # de "INTEGER"/"SMALLINT"/"TIMESTAMP" — comparando el texto crudo, esas columnas nunca
+            # coincidirían con la realidad y se propondría un ALTER COLUMN ... TYPE en cada
+            # ejecución aunque el tipo real no cambie (inofensivo casi siempre, pero Postgres lo
+            # rechaza si otra columna GENERATED depende de la columna "alterada").
             return (
-                norm(col_real.tipo) == norm(col_def.tipo) and
+                col_real._tipo_base() == col_def._tipo_base() and
                 col_real.longitud == col_def.longitud and
                 col_real.precision == col_def.precision and
                 (col_real.escala or None) == (col_def.escala or None)
@@ -771,6 +790,16 @@ class Tabla:
             col_real = reales.get(nombre)
             if not col_real:
                 col_alteraciones.append(f"ADD COLUMN {col_def.to_sql()}")
+            elif col_def.generado:
+                # Las columnas GENERATED ALWAYS AS (...) STORED no se comparan ni se alteran
+                # automáticamente una vez existen: la introspección no reconstruye la expresión
+                # de generación (obtener_columnas_postgres no la lee), así que cualquier columna
+                # "normal" reconstruida a partir de una generada se compararía con datos
+                # incompletos (p.ej. sin el NOT NULL que sí lleva la generada) y dispararía un
+                # ALTER espurio — que además Postgres puede rechazar de plano si otras columnas
+                # dependen de ella. Si la expresión cambia, hay que borrar y recrear la columna
+                # a mano.
+                continue
             elif not iguales(col_real, col_def):
                 if not tipos_iguales(col_real, col_def):
                     tipo_sql = col_def._tipo_sql()
@@ -1195,6 +1224,21 @@ class ManagerDB(Database):
                     )
                 """)
 
+                # Tablas que ya existían ANTES de esta llamada: solo tiene sentido comparar
+                # (y potencialmente ALTERar) esas. Una tabla recién creada en esta misma llamada
+                # coincide por definición con el modelo que la creó — compararla igual puede
+                # disparar un ALTER falso-positivo (p.ej. no detecta que "INT" y "INTEGER" son el
+                # mismo tipo) que además Postgres puede rechazar de plano si hay una columna
+                # GENERATED que depende de la columna "alterada".
+                tablas_preexistentes = set()
+                for nombre_tabla in self.tablas:
+                    cursor.execute(
+                        "SELECT 1 FROM information_schema.tables WHERE table_schema = 'public' AND table_name = %s",
+                        (nombre_tabla,)
+                    )
+                    if cursor.fetchone():
+                        tablas_preexistentes.add(nombre_tabla)
+
                 # --- Crear tablas nuevas (+ índices + comentarios) ---
                 for nombre_tabla, tabla in self.tablas.items():
                     sentencias_creacion = [tabla.to_sql()] + tabla.to_sql_indices() + tabla.to_sql_comentarios()
@@ -1206,8 +1250,10 @@ class ManagerDB(Database):
                     if self.logger:
                         self.logger.info(f"Tabla \"{nombre_tabla}\": ejecutado CREATE IF NOT EXISTS.")
 
-                # --- Aplicar ALTERs ---
+                # --- Aplicar ALTERs (solo en tablas que ya existían antes de esta llamada) ---
                 for nombre_tabla, tabla in self.tablas.items():
+                    if nombre_tabla not in tablas_preexistentes:
+                        continue
                     alter_sqls = tabla.comparar_generar_alter(conexion, permitir_drop=permitir_drop)
                     for alter_sql in alter_sqls:
                         cursor.execute(alter_sql)

{mtpk_postgres-0.1.2 → mtpk_postgres-0.1.4}/mtpk_postgres.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mtpk_postgres
-Version: 0.1.2
+Version: 0.1.4
 Summary: Librería para sincronización estructural de bases de datos Postgres con modelos Python (adaptación de mtpk_mariadb)
 Author-email: José Jesús Andrés Zambrana <jjandres@multiplika.es>
 License: MIT
@@ -54,6 +54,26 @@ pip install -e .
 
 ## Historial
 
+- **0.1.4**: corrige la causa de fondo del bug de la 0.1.3, que solo tapaba el síntoma en la columna generada
+  en sí. Había dos problemas relacionados: (1) `comparar_generar_alter` comparaba el tipo de columna por su
+  nombre "en crudo" (`col.tipo`), así que un modelo que usa alias como `INT`, `TINYINT` o `DATETIME` (en vez de
+  `INTEGER`/`SMALLINT`/`TIMESTAMP`, que es como se reconstruyen siempre desde Postgres) nunca coincidía con la
+  realidad y proponía un `ALTER COLUMN ... TYPE` en cada ejecución aunque el tipo no hubiera cambiado — inofensivo
+  la mayoría de las veces (Postgres permite "cambiar" una columna a su mismo tipo), pero rechazado de plano si otra
+  columna `GENERATED` depende de la columna "alterada"; ahora se compara por el tipo canónico
+  (`Columna._tipo_base()`). (2) `ManagerDB.aplicar_cambios()` — la ruta que se usa en la primera sincronización de
+  una base de datos nueva — creaba todas las tablas del modelo y a continuación las volvía a comparar todas,
+  incluidas las que acababa de crear en la misma llamada; una tabla recién creada coincide por definición con el
+  modelo que la creó, así que ahora se excluye de esa comparación (que solo tiene sentido sobre tablas
+  preexistentes). Esta segunda corrección evita esta clase entera de falsos positivos, no solo el caso ya visto.
+- **0.1.3**: corrige un bug bloqueante en `comparar_generar_alter` — al crear una tabla nueva con una columna
+  `GENERATED ALWAYS AS (...) STORED` (p.ej. una columna de búsqueda `tsvector` calculada a partir de otra), la
+  siguiente pasada de comparación la trataba como una columna normal (la introspección no reconstruye la expresión
+  de generación) y proponía un `ALTER COLUMN` sobre ella justo después de crearla — algo que Postgres puede
+  rechazar cuando otras columnas dependen de la generada. Como `aplicar_cambios()` ejecuta todo en una única
+  transacción, ese fallo deshacía también la creación de las demás tablas. Ahora las columnas `generado` nunca se
+  comparan ni se alteran una vez existen (para cambiar su expresión hay que borrarlas y recrearlas a mano); de paso,
+  `Columna.to_sql()` ya respeta `not_null=True` en columnas generadas (antes se ignoraba).
 - **0.1.2**: soporte nativo para columnas `VECTOR(n)` (pgvector) e índices con método (`USING gin/hnsw/...`,
   `opclass`, `WITH (...)`) en `Index`. La introspección (`obtener_columnas_postgres`) ahora reconoce las columnas
   `vector` por su `udt_name` y reconstruye su dimensión leyendo el catálogo (`pg_attribute`/`format_type`); sin esto,

{mtpk_postgres-0.1.2 → mtpk_postgres-0.1.4}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "mtpk_postgres"
-version = "0.1.2"
+version = "0.1.4"
 description = "Librería para sincronización estructural de bases de datos Postgres con modelos Python (adaptación de mtpk_mariadb)"
 readme = "README.md"
 requires-python = ">=3.9"