mtpk-postgres 0.1.3__tar.gz → 0.1.5__tar.gz

{mtpk_postgres-0.1.3 → mtpk_postgres-0.1.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mtpk_postgres
-Version: 0.1.3
+Version: 0.1.5
 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,24 @@ pip install -e .
 
 ## Historial
 
+- **0.1.5**: corrige `AsyncCrudBase.insert()`/`insertar()` (y en general cualquier `AsyncDatabase._query_accion`
+  con `RETURNING`), que fallaban siempre con `KeyError: 0`. Las conexiones async se abren con
+  `row_factory=dict_row` para que las lecturas devuelvan diccionarios, pero `_query_accion` reutilizaba ese mismo
+  row_factory para leer el valor de `RETURNING id` como `fila[0]` — con `dict_row`, `fila` es un `dict` sin clave
+  `0`. Ahora ese cursor se abre explícitamente con `row_factory=tuple_row`. Sin este arreglo, cualquier alta de
+  registro (`insert`) fallaba siempre; la sincronización de esquema (crear/comparar tablas) no estaba afectada.
+- **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

{mtpk_postgres-0.1.3 → mtpk_postgres-0.1.5}/README.md

@@ -34,6 +34,24 @@ pip install -e .
 
 ## Historial
 
+- **0.1.5**: corrige `AsyncCrudBase.insert()`/`insertar()` (y en general cualquier `AsyncDatabase._query_accion`
+  con `RETURNING`), que fallaban siempre con `KeyError: 0`. Las conexiones async se abren con
+  `row_factory=dict_row` para que las lecturas devuelvan diccionarios, pero `_query_accion` reutilizaba ese mismo
+  row_factory para leer el valor de `RETURNING id` como `fila[0]` — con `dict_row`, `fila` es un `dict` sin clave
+  `0`. Ahora ese cursor se abre explícitamente con `row_factory=tuple_row`. Sin este arreglo, cualquier alta de
+  registro (`insert`) fallaba siempre; la sincronización de esquema (crear/comparar tablas) no estaba afectada.
+- **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

{mtpk_postgres-0.1.3 → mtpk_postgres-0.1.5}/mtpk_postgres/__init__.py

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

{mtpk_postgres-0.1.3 → mtpk_postgres-0.1.5}/mtpk_postgres/async_adapter.py

@@ -9,7 +9,7 @@
 # Esta librería es un wrapper (envolvente) del conector psycopg para manejo de Postgres con funciones asíncronas.
 
 import psycopg
-from psycopg.rows import dict_row
+from psycopg.rows import dict_row, tuple_row
 from typing import Optional, Union, List, Dict
 from .core_sync import Tabla, SQLLiteral
 from logging import Logger
@@ -261,9 +261,15 @@ class AsyncDatabase:
         INSERT/UPDATE/DELETE/etc. Postgres no tiene `lastrowid`: si la sentencia incluye una
         cláusula RETURNING, el primer valor de la primera fila devuelta se guarda en
         `self.ultimo_insert_id`. Devuelve el número de filas afectadas.
+
+        El cursor se abre explícitamente con `row_factory=tuple_row`: tanto `conexion` (si viene
+        de `transaccion()`) como las conexiones de `_PseudoPool` se crean con `row_factory=dict_row`
+        para que `_query_select` devuelva dicts, pero aquí necesitamos `fila[0]` (primera columna
+        del RETURNING) — con el row_factory heredado de la conexión, `fila` sería un dict y
+        `fila[0]` lanzaría KeyError: 0 en vez de darnos el id.
         """
         if conexion is not None:
-            async with conexion.cursor() as cursor:
+            async with conexion.cursor(row_factory=tuple_row) as cursor:
                 await cursor.execute(sql, params)
                 filas = cursor.rowcount
                 if cursor.description:
@@ -277,7 +283,7 @@ class AsyncDatabase:
 
             async with self.pool.acquire() as cx:
                 try:
-                    async with cx.cursor() as cursor:
+                    async with cx.cursor(row_factory=tuple_row) as cursor:
                         await cursor.execute(sql, params)
                         filas = cursor.rowcount
                         if cursor.description:

{mtpk_postgres-0.1.3 → mtpk_postgres-0.1.5}/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:
@@ -750,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)
@@ -1207,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()
@@ -1218,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.3 → mtpk_postgres-0.1.5}/mtpk_postgres.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mtpk_postgres
-Version: 0.1.3
+Version: 0.1.5
 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,24 @@ pip install -e .
 
 ## Historial
 
+- **0.1.5**: corrige `AsyncCrudBase.insert()`/`insertar()` (y en general cualquier `AsyncDatabase._query_accion`
+  con `RETURNING`), que fallaban siempre con `KeyError: 0`. Las conexiones async se abren con
+  `row_factory=dict_row` para que las lecturas devuelvan diccionarios, pero `_query_accion` reutilizaba ese mismo
+  row_factory para leer el valor de `RETURNING id` como `fila[0]` — con `dict_row`, `fila` es un `dict` sin clave
+  `0`. Ahora ese cursor se abre explícitamente con `row_factory=tuple_row`. Sin este arreglo, cualquier alta de
+  registro (`insert`) fallaba siempre; la sincronización de esquema (crear/comparar tablas) no estaba afectada.
+- **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

{mtpk_postgres-0.1.3 → mtpk_postgres-0.1.5}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "mtpk_postgres"
-version = "0.1.3"
+version = "0.1.5"
 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"