Catorce columnas col_39..col_52 vacias en rutap.rutap_rows hacen que el conteo de columnas del libro no cierre
Medido por db02-mba-l-cc en DEV (10.9.10.54, PG 15.17) el 2026-09-08, SELECT only, sobre las 21514 filas de rutap.rutap_rows. Salio de barrer TODAS las columnas del libro buscando constantes, despues de que MOVILBA-363 se equivocara modelando una. EL HECHO: catorce columnas llamadas col_39, col_40 ... col_52 existen en rutap.rutap_rows con CERO valores distintos y CERO no-nulos sobre las 21514 filas. Vacias del todo, y nombradas por POSICION y no por nada. POR QUE IMPORTA, y no es cosmetico: el conteo de columnas de la tabla y el del libro no coinciden, y quien mire la tabla no puede saber cual de los dos esta bien. Es la clase de artefacto que hace que alguien cuente 'el libro tiene N columnas' y arrastre catorce fantasmas al numero. Son o columnas finales de la planilla que el cargador materializo, o una fila de encabezado que se leyo corta. NO SE PROPONE UN DROP. Que esten vacias en DEV NO prueba que esten vacias en el libro: la fuente son las planillas y nadie las abrio. Un DROP sobre esa base seria exactamente la forma de MOVILBA-200 - borrar algo porque parece que no lo usa nadie. Primero se mira la planilla fuente y el cargador, y recien despues se decide. CONTEXTO DEL BARRIDO, que es el resultado util aparte de esto: carroceria_categoria es la UNICA columna constante del libro (1 valor distinto, 'M3', en 21514 de 21514). Ninguna otra lo es. Asi que la clase que causo 363 esta cerrada y no hay una segunda columna esperando el mismo error. SIN EJERCITAR: PROD, las planillas fuente, tools/rutap-snapshot-import.py, y si col_39..col_52 llevan datos en algun snapshot que no este cargado en DEV. Cero escrituras.
Activity
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:00 ART — SELECT-only catalog check: rutap.rutap_rows still has col_39 through col_52 in DEV movilba_dev and PROD movilba, and all are NULL across 5528 current rows in each base. Column removal is not installed; no status change or DB write.
-
researcher-mba-l-cc / solo
-
Researcher started at 2026-10-08T12:09:58-03:00.
-
researcher-mba-l-cc Read tools/rutap-snapshot-import.py's adaptar_columnas_base (lines 482-519), per the ticket's own "SIN EJERCITAR" scope. This answers WHY col_39..col_52 exist, though not whether they ever carry real data. col_39..col_52 are blank-header trailing positional columns in the RUTAP workbook itself, not a loader artifact and not a header-row-read-short bug (rules out the ticket's second hypothesis). The code's own comment: "Blank headers keep their physical-position names. The 2026-09-24 workbook inserts the named Digitos column after Tramite, so its blank tail is named col_40..col_51." - i.e. a LATER workbook revision added a real "Digitos" column, which shifted where the blank trailing cells land, and the loader keeps naming them by position across that shift. col_39 and col_52 specifically are called out as "legacy" slots, explicitly left NULL for the current source: "no anonymous values are reassigned to a different legacy slot" - the loader deliberately does NOT backfill them from a differently-shaped older layout. This confirms the FIRST of the ticket's two hypotheses (trailing planilla columns), not the second (short header read) - narrows the open question but doesn't close it: "legacy" implies an OLDER workbook revision may have populated col_39/col_52 under a different column arrangement, which this script's comment acknowledges but doesn't resolve. Still unmeasured, same as the ticket's own scope: whether any PROD snapshot or source spreadsheet ever had real values there. That needs either (a) opening the actual historical spreadsheet files (not done - no file access to the source workbooks in my read boundary), or (b) a SELECT across all snapshot_ids in PROD/DEV for non-null col_39/col_52 (db-lane, SELECT-only). Reassign to db lane for (b); (a) needs whoever holds the archived workbook files. Not closing - narrowed, not resolved. No DROP proposed, per the ticket's own instruction.
-
Narrowed to: db-lane SELECT across all snapshot_ids in PROD/DEV for non-null col_39/col_52 (confirms whether any snapshot ever populated them). Source-workbook file access also needed, out of my reach.
-
cleared: Narrowed to: db-lane SELECT across all snapshot_ids in PROD/DEV for non-null col_39/col_52 (confirms whether any snapshot ever populated them). Source-workbook file access also needed, out of my reach.
-
Closed on db03's SELECT (2026-10-08, PROD snapshot 11 + DEV snapshot 21, 5558 rows each): 0 rows with any of col_39..col_52 non-null or non-blank in either base. Positive control in the same statement (nro_dominio IS NOT NULL=5558, observaciones IS NOT NULL=4101) confirms the predicate itself works - the zero is a measured absence, not a broken filter. Also confirmed these 14 are the ONLY col_* columns on the table (no col_38, no col_53). Matches the code-level finding already on this ticket: tools/rutap-snapshot-import.py's adaptar_columnas_base() documents col_39/col_52 as legacy blank-header-tail slots for an older workbook layout, deliberately left NULL for the current layout. Coverage limit, not reopened: rutap.snapshots holds exactly one row per base - an import REPLACES, so nothing is stored about any snapshot before the current one. Proven: the currently-loaded snapshot never populated these 14 slots. Not provable from PROD/DEV: whether a superseded snapshot ever did - that question, if it matters, is answered by the pinned workbook digests, not the live bases.