406 filas de historial cerradas que el libro vigente no trae: excedentes solo al contar las cerradas, y la ficha las dibuja como periodo
MEDIDO por db02-mba-l-cc y db03-mba-l-ca el 2026-09-05 07:34 en DEV, desde dos instrumentos distintos. Sale de la cobertura de las 709 filas excedentes que db03 exporto desde el loader de MOVILBA-227. LAS 709 SE PARTEN ASI: 108 son exactamente las filas que repara MOVILBA-255 (una por par, sin superposicion ni casi-coincidencia - dos carriles con dos instrumentos llegaron al mismo conjunto), 91 caen en MOVILBA-260, y 510 no las cubre ninguno de los dos. ESTE ITEM ES EL GRUESO DE ESAS 510: 406 filas ACTIVAS cuyo grupo (vehiculo_id, fecha_alta) tiene UNA SOLA fila activa. O sea que NO son el defecto de 255 ('dos filas abiertas para un mismo periodo'). Son excedentes solo cuando se cuentan tambien las filas CERRADAS: nuestra tabla guarda mas filas de periodo que las que el libro trae para esa apertura, y las de mas ya estan cerradas. LA PREGUNTA QUE HAY QUE CONTESTAR PRIMERO, y no esta contestada: una fila de periodo cerrada que el libro vigente NO trae, es un defecto o no? Las dos respuestas son defendibles y la decision cambia todo lo demas: - Si NO lo es, esto se cierra sin escribir una linea: el libro es un snapshot y no pretende ser el ledger completo, y nuestra tabla conserva historia que el libro ya no lista. - Si SI lo es, son 406 filas que la ficha muestra. Y las muestra: borrado_en en vehiculo_historial NO significa borrado, guarda la Fecha Baja del libro (MOVILBA-83), asi que una fila cerrada se RENDERIZA como un periodo cerrado en vez de desaparecer. Es el mismo defecto visible de MOVILBA-170 y MOVILBA-225 llegando por una tercera puerta. NO PLEGAR ESTO DENTRO DE MOVILBA-260 sin contestar eso: 260 es 'grupos con historial activo duplicado' y esta forma no es esa. Meterlas ahi le cambia la poblacion a un item que ya tiene su medicion hecha. LAS OTRAS 95 de las 510 son otra clase todavia: aperturas que el snapshot vigente no trae en absoluto. No se borran y no se mezclan aca. NO EJERCITADO: nadie abrio la ficha de uno de estos 406 para ver que dibuja. Esa es la medicion que vuelve la pregunta concreta.
Activity
-
db02 2026-09-05, LA PREGUNTA DEL ITEM CONTESTADA CON UNA MEDICION Y NO CON UN ARGUMENTO. Todo SELECT, DEV, contra el libro vigente rutap.v_rutap_latest snapshot 11 (5388 filas / 2407 dominios). LA POBLACION RE-DERIVADA, desde otra direccion que db03: "excedente" = por (dominio plegado, fecha_alta) nuestra tabla tiene MAS filas que el libro para esa apertura. Resultado: 709 filas excedentes en 709 grupos, y CERO grupos donde el libro tenga mas que nosotros. Denominadores: 6097 filas en public.vehiculo_historial sobre 5467 grupos, 5388 filas de libro. Dos carriles, dos instrumentos, la misma poblacion. LA CIFRA DEL TITULO SE MOVIO Y DIGO POR QUE, no la dejo pasar en silencio: el item dice 406 filas activas en grupos con una sola activa. Hoy son 522. El movimiento es MOVILBA-255: al retirar 107 filas abiertas duplicadas, esos 107 grupos pasaron de "dos activas" a "una sola activa" y entraron en esta clase. Mas el import de las 07:46 (19 filas, snapshot 11) que agrego algunas. El reparto de hoy de las 709: 95 en grupos que el libro NO trae en absoluto, 522 en grupos con exactamente UNA fila activa, 92 en grupos con varias activas. 95+522+92 = 709. LA RESPUESTA A "ES UN DEFECTO O NO": NO SE RENDERIZA. Y no es deduccion del codigo, es medicion en dos pasos. 1. La ficha lee rutap.vehiculo_historial_normalizado desde el cutover de MOVILBA-204, no public.vehiculo_historial. 2. La tabla ancha es un ESPEJO FIEL del libro y NO tiene el excedente: medida contra el libro por (dominio, fecha_alta), de sus 5354 grupos tiene de mas en UNO SOLO (una fila) y de menos en NINGUNO. Nuestra tabla de historial excede en 709; el espejo excede en 1. 3. Verificado al nivel del RENDER, por casualidad y por eso vale: AA217GK es uno de los 709 (2 filas nuestras contra 1 del libro para fecha_alta 2026-06-29) y es uno de los tres dominios que proxy-mba-w-cc abrio para el chequeo de 255. Su ficha dibujo 4 periodos, que es lo que trae la ancha, no 5. La fila excedente NO aparece. CONCLUSION: una fila de periodo cerrada que el libro vigente no trae NO es un defecto de cara al usuario, porque ningun usuario la ve. Es una divergencia interna entre public.vehiculo_historial y el libro. Las 709 no se borran, no se pliegan en MOVILBA-260, y no justifican ninguna escritura hoy. LO QUE SI ES: la evidencia de que public.vehiculo_historial dejo de ser la fuente de la ficha y nadie decidio que ES ahora. Mientras siga acumulando filas que el libro no tiene y que nada lee, cada import la aleja mas. La pregunta que reemplaza a la de este item es de MODELO y no de datos: esa tabla es un ledger append-only que conserva historia que el libro ya no lista, o es un espejo que deberia coincidir? Las dos respuestas son defendibles y ninguna esta escrita en ningun lado. Hasta que se conteste, cualquier limpieza de las 709 es elegir una de las dos sin decirlo. DOS COSAS QUE APARECIERON DE PASO: - La tabla ancha excede al libro en UN grupo (una fila) que el libro 11 no trae. Es chico pero no es cero, y la ancha esta en snapshot 10 mientras el libro esta en 11 (MOVILBA-269), asi que esa unica diferencia puede ser justamente el desfasaje. No se investigo. - Los 95 grupos que el libro no trae en absoluto son otra clase todavia, y NO son las filas de prueba de MOVILBA-278 (esas son 5 filas de vehiculos, no de historial). NO EJERCITADO: no se abrio ninguna ficha a proposito para esto - el caso AA217GK es reuso de una lectura hecha para 255; no se midio PROD; no se identifico la unica fila en que la ancha excede al libro; no se comparo el CONTENIDO de las filas excedentes contra el libro, solo la cardinalidad.
-
db03-mba-l-cc
-
db03 2026-09-18 ~12:40 ART. RE-MEASURED today, SELECT only, DEV + PROD (PROD as svc_nextjs). The population this item counted no longer exists, and the model question it deferred was answered by MOVILBA-441. 1. public.vehiculo_historial - the table the 406/709 excess rows lived in - does not exist in DEV or in PROD (to_regclass NULL both). PROD: dropped without CASCADE by 441 on 2026-09-17. The ficha reads rutap.vehiculo_historial_normalizado via rutap.v_vehiculo_historial_normalizado_fuente_actual. The question the 09-05 verification turned it into - is that table an append-only ledger or a mirror of the book - is answered: mirror; the canonical reader is book-derived. 2. Successor measured against the current book by (snapshot_id, fila): PROD hist_norm 5514 rows, all in snapshot 2, 3914 closed / 5514 elegible_actual; book v_rutap_latest_norm 5514 rows, 3914 closed. Rows in hist_norm with no book row (excess): 0. Book rows with no hist_norm row: 0. Unique index vh_norm_raw_key on (rutap_snapshot_id, rutap_fila_excel), and (rutap_snapshot_id, rutap_fila) has 5514 distinct in 5514 rows, so the two zeros are a bijection, not a coincidence of counts. Closed-row excess the ficha could draw: 0. 3. DEV: same 5514/5514, excess 0, missing 0. Plus 95 rows with NULL rutap_snapshot_id (53 closed, elegible_actual false), normalizado_por 'app-create-colectivo' (28 rows/27 dominios) and 'app-editar-colectivo' (67 rows/41 dominios), written 2026-09-07..09-18. Those are periods created by users through the UI - user-created DEV data, not the import's, and not a book-excess class. PROD has 0 such rows (nobody has edited there). 4. Control: the anti-join ran on both directions and on both environments and the population it counts is enumerable (the 95 DEV rows show up when the filter is flipped), so a zero is not an empty predicate. NOT EXERCISED: no ficha was opened; PROD hist_norm read through the base table (svc_nextjs has no SELECT on the _fuente_actual view - permission denied, which I hit and did not treat as absence); content of rows, only cardinality by key. Closing. No write.
-
db03 2026-09-18: closed on today's re-measurement, see the last event on this item.