movilba
MOVILBA-270
Dos filas de vehiculos con el mismo dominio AG045KB: el upsert por dominio no tiene un id que preservar, tiene dos
Done high
dmdb03-mba-l-cc
MEDIDO por db02-mba-l-cc el 2026-09-05 07:34 en DEV, al rehearsear las dos ramas de MOVILBA-200. No es de ese archivo y no se arregla ahi. El chasis muerto id 8 tiene DOS filas de 'vehiculos' con EL MISMO dominio AG045KB. Aparecio contando 'los vehiculos de la fila 8' y encontrando dos donde el libro tiene un colectivo. POR QUE IMPORTA: el dominio es el identificador del colectivo puertas afuera (regla permanente: en un documento de stakeholder el id de un colectivo es el dominio). Dos filas con el mismo dominio significa que cualquier lectura por dominio devuelve una de las dos sin criterio, y que el upsert del import 'por dominio preservando el id' no tiene un id que preservar - tiene dos. QUE HAY QUE MEDIR ANTES DE TOCAR NADA: 1. Cuantos dominios tienen mas de una fila en 'vehiculos' - AG045KB puede no ser el unico; medir la CLASE, no el caso. 2. Para cada uno, cual de las dos filas esta referenciada por vehiculos_datos_colectivos, vehiculo_historial, validadoras y audit_log. La que tiene historia colgando no se toca. 3. Si las dos tienen referencias, es una fusion y no un borrado, y la decision es de Elazar. NO ES UN BORRADO POR DEFECTO. 'baja' es un estado, nunca una eliminacion. Una fila duplicada sin ninguna referencia es candidata a retiro; una con referencias es una fusion. CONTEXTO: AG045KB ya aparecio en el tracker de Eugenia como asunto 30 (numero de chasis cortado, corregido por ella en el libro del 20/08). Que el mismo dominio vuelva a aparecer con otro defecto no es casualidad y vale mirarlo junto.
Activity
-
db02 2026-09-05, LA CLASE MEDIDA EN DEV. Todo SELECT, nada escrito. Denominadores re-derivados: public.vehiculos tiene 2443 filas y 2425 dominios distintos (plegando no-alfanumericos y mayusculas). CORRECCION A LO QUE YO MISMO DIJE: AG045KB no tiene DOS filas, tiene TRES (5203, 5204, ambas con borrado_en, y 5624 viva). Conte "los vehiculos del chasis 8" y ahi eran dos; el dominio tiene tres. LA CLASE: 11 dominios con mas de una fila, 29 filas involucradas, o sea 18 filas de mas. AG045KB no es el unico ni el peor: NEA182 tiene OCHO filas. REPARTO POR VIVAS (viva = borrado_en IS NULL en public.vehiculos, que es lo que indexa uq_vehiculos_dominio_active; NO es el test de liveness del vehiculo, que es estado_id via vehiculos_datos_colectivos): - 0 dominios con mas de una fila viva. El unique index parcial se sostiene: esto NO es una violacion de unicidad, son filas retiradas que quedaron colgadas. - 9 dominios con exactamente una viva y el resto retiradas. - 2 dominios sin ninguna viva: AI088HH (2 filas) y NEA182 (8 filas). DETALLE, id | dominio | retirada | hist | vdc | validadoras | deudas | tabla_ancha | audit_log: 3801 AE100DB t 1 1 0 0 0 0 | 6025 AE100DB f 6 1 0 1 4 0 3805 AE100DF t 1 1 0 0 0 0 | 6026 AE100DF f 6 1 0 1 4 0 5207 AE971GV t 0 1 0 0 0 1 | 5208 AE971GV f 2 1 0 0 2 2 4399 AF928IF t 0 1 0 0 0 1 | 6029 AF928IF f 6 1 0 1 4 0 5203 AG045KB t 0 1 0 0 0 2 | 5204 AG045KB t 0 1 0 0 0 3 | 5624 AG045KB f 3 1 0 0 2 0 4564 AH152NT t 0 1 0 0 0 0 | 6030 AH152NT f 5 1 0 1 3 0 5233 AI086GZ t 0 0 0 0 0 1 | 6617 AI086GZ f 1 1 0 1 1 0 5226 AI086HB t 0 0 0 0 0 1 | 6618 AI086HB f 1 1 0 1 1 0 5230 AI088HH t 0 0 0 0 0 1 | 5245 AI088HH t 0 0 0 1 0 1 5920 DHU474 t 0 1 0 1 0 1 | 6621 DHU474 f 1 1 0 1 0 2 NEA182: 5184 5185 5186 5187 5188 5215 5216 5251, las OCHO retiradas, las ocho con una fila de vehiculos_datos_colectivos, cero historial, cero tabla ancha. LO QUE ESTO CAMBIA, y es la razon por la que no es un borrado: 1. NINGUNA fila retirada esta sin referencias. 26 de las 29 tienen una fila en vehiculos_datos_colectivos - o sea la FICHA existe para la fila retirada. Solo 3 (5233, 5226, 5230) no la tienen. "Fila duplicada sin ninguna referencia" no describe a casi ninguna: la clase candidata a retiro simple esta vacia salvo esas tres, y hasta esas tienen audit_log. 2. HAY PLATA COLGANDO DE UNA FILA RETIRADA. rendiciones.deudas_dominios apunta a 5920 (DHU474, retirada) Y a 6621 (DHU474, viva): el mismo dominio con deuda repartida entre las dos filas. Y a 5245 (AI088HH), que es una fila retirada de un dominio SIN NINGUNA fila viva - esa deuda no cuelga de ningun vehiculo vivo. Eso es una fusion, con dinero adentro, y la decision es de Elazar. 3. Dos filas tienen historial DE LOS DOS LADOS: AE100DB (1 en la retirada, 6 en la viva) y AE100DF (1 / 6). Ahi ninguna se toca sin decidir que pasa con la fila de historial de la retirada. 4. Cinco dominios (AE100DB, AE100DF, AF928IF, AH152NT) tienen la fila VIVA creada el 2026-08-05 y la retirada el 2025-12-08. La forma es "el import de agosto creo una fila nueva en vez de reusar la vieja", que es exactamente lo que reference_el_import_reconcilia_por_upsert_no_trunca dice que NO debe pasar. NEA182 y AI088HH no tienen fila viva y ese es otro caso: el upsert por dominio de un import futuro tendria que elegir entre 8 ids retirados. NO EJERCITADO: no abri ninguna ficha; no medi si las dos filas de un mismo dominio difieren en el CONTENIDO (chasis, entidad, datos del colectivo) - solo conte referencias; no toque PROD ni medi si la clase existe alli; y no busque duplicados por otra clave que no sea el dominio plegado.
-
db02 2026-09-05, CAUSA Y NO RESIDUO: cuatro dominios (AE100DB, AE100DF, AF928IF, AH152NT) tienen la fila VIVA creada el 2026-08-05 al lado de una RETIRADA del 2025-12-08, y la misma forma se repite en PROD con nueve dominios (retirada vieja + viva del import de agosto: 2026-08-05 x4, 2026-08-14, 2026-08-25 x2). El import de agosto creo una fila NUEVA en vez de reusar el id existente, que es precisamente lo que reference_el_import_reconcilia_por_upsert_no_trunca existe para impedir. ESTE ITEM NO ES UNA LIMPIEZA DE DATOS: es un defecto del loader con residuo. Quien lo tome no debe fusionar filas y dejar la causa corriendo - primero el loader, si no el proximo import vuelve a crear el par.
-
db02 2026-09-05, EL CONTENIDO DE LAS FILAS APAREADAS, que era lo que faltaba para que la fusion sea decidible. Todo SELECT en DEV. Se comparan los 9 dominios con exactamente una fila viva (AI088HH y NEA182 quedan afuera: no tienen ninguna viva). LAS DOS FILAS NUNCA SON IGUALES. En los 10 pares (AG045KB aporta dos) difiere al menos una de chasis_id, carroceria_id, anio_modelo, numero_serie_chasis, numero_serie_motor, subtipo o motor_fabricante_id. O sea que ninguna fusion es "quedarse con cualquiera". LA FORMA GENERAL ES "LA RETIRADA ES MAS POBRE": motor_fabricante_id esta NULL en las 10 retiradas y poblado en 8 de las 9 vivas. AE971GV 5207 y AI086GZ 5233 y AI086HB 5226 estan practicamente vacias. Para esos casos fusionar es descartar la retirada. PERO HAY TRES DONDE LA RETIRADA TIENE ALGO QUE LA VIVA NO, y ahi descartar PIERDE dato: 1. AF928IF: la retirada (4399) tiene chasis_id 4; la VIVA (6029) tiene chasis_id NULL. El libro dice MERCEDES BENZ / O 500 U para ese dominio. 2. AE100DB y AE100DF: la retirada tiene carroceria_id 33, la viva 5. Son carrocerias distintas, no una vacia. 3. DHU474: la retirada (5920) tiene carroceria_id 12 y la viva (6621) la tiene NULL. DOS DEFECTOS APARTE QUE APARECIERON MIRANDO ESTO, y ninguno es de la fusion: A. DHU474 NO EXISTE EN EL LIBRO y su fila VIVA es basura de prueba: numero_serie_chasis = 'ASDASD55A55', subtipo 6 contra 17 de la retirada, sin anio en la retirada. Cero filas en rutap.v_rutap_latest para ese dominio. Es un vehiculo de test que quedo en DEV, y es ADEMAS uno de los dos dominios con deuda en rendiciones.deudas_dominios repartida entre las dos filas. B. UN NUMERO DE CHASIS ESTA EN CUATRO FILAS DE VEHICULOS. El libro dice AI086GZ = LA6C3K1GXTB101962 y AI086HB = LA6C3K1G6TB102087, distintos. En DEV, LA6C3K1G6TB102087 aparece en CUATRO filas: 5226 (AI086HB, retirada), 5233 (AI086GZ, retirada - le corresponde el OTRO numero), 6618 (AI086HB, viva, correcta) y 5819 (AH846SI, VIVA y de otro dominio). Las filas 6618 y 5819 comparten numero de chasis estando las DOS vivas, que es la parte grave. Las filas VIVAS de AI086GZ y AI086HB si coinciden con el libro; el defecto son las dos retiradas mas la colision con AH846SI, que no es parte de este item y necesita el suyo. CONSECUENCIA PARA LA DECISION: no es "borrar la retirada". Por dominio hay que decidir campo por campo cual valor sobrevive, y para los tres casos de arriba el valor de la retirada es el unico que hay. La regla que si se sostiene con evidencia es que el DOMINIO se resuelve a la fila VIVA (medido: en los 8 dominios que aparecen en la tabla ancha, las 9 filas de la ancha apuntan a la fila VIVA y nunca a la retirada). NO EJERCITADO: no se comparo campo por campo contra el libro salvo chasis_nro y ano_modelo; no se miro vehiculos_datos_colectivos de cada lado (solo se conto que existe); PROD no se midio para el contenido, solo para la clase.
-
db02 2026-09-05: HOJA DE FUSION ESCRITA, NO APLICADA, SIN GO. /data-lezama/import-reports/2026-09-05-movilba-270-hoja-de-fusion-DEV.md. Campo por campo sobre los 9 dominios con exactamente una fila viva; DHU474 excluido (MOVILBA-278), AI088HH y NEA182 fuera por no tener ninguna viva. SE CAE UNA DE LAS TRES EXCEPCIONES Y ES LA QUE IBA A IR A EUGENIA. Se habia dicho que AE100DB y AE100DF tenian dos carrocerias distintas y pobladas (33 retirada contra 5 viva) y que eso era una pregunta. MEDIDO: carrocerias.id 33 y 5 son EL MISMO TEXTO, ITALBUS / ITALBUS, y la 33 es una fila de catalogo DUPLICADA Y YA RETIRADA con cero vehiculos vivos. La fila viva ya apunta a la sobreviviente. No hay diferencia de datos y no hay pregunta. Y EL CATALOGO ENTERO TIENE LA ENFERMEDAD DE MOVILBA-200 EN OTRA TABLA: 13 textos de carroceria con entre 2 y 9 filas cada uno - AUTOBUS 8 (1,19..23,73,74), TODO BUS/TODOBUS 9 (13,51..58), HEPRICAR 7, ITALBUS 6, METALPAR 6, LA FAVORITA 6, NUOVOBUS 5, MARCOPOLO 4, UGARTE 4, BAM BAM 3, CORWIN 3, KING LONG 2, METALBUS 2. Item propio, no se toca desde aca. QUEDA UNA SOLA EXCEPCION REAL: AF928IF. La retirada 4399 tiene chasis_id 4 y la VIVA 6029 lo tiene NULL, asi que descartar la retirada pierde el unico valor que hay; y la carroceria esta contradicha por el libro TRES veces para ese dominio (HEPRICAR, NUOVOBUS y BAM BAM). Se reporta, no se pregunta. AE100DF queda bloqueado por otra cosa: el libro trae DOS grafias de chasis para el mismo dominio (1721L62 CA y OH 1721 L-SB/62). Es la misma decision de grafia de MOVILBA-200 y sale con 200, no aca. Los otros seis (AE100DB, AE971GV, AG045KB con sus DOS retiradas, AH152NT, AI086GZ, AI086HB) resuelven limpio: la fila viva sobrevive en todos los campos y la retirada no aporta nada. En AI086GZ la retirada trae ademas un numero de chasis que el libro le asigna a OTRO dominio, asi que su valor es incorrecto y no es un dato que se pierda. NO EJERCITADO: ningun UPDATE, ningun GO pedido; no se comparo vehiculos_datos_colectivos de cada lado; el contenido de los pares en PROD no se midio (solo la clase, 9 dominios / 19 filas); no se decidio que pasa con las filas de vehiculo_historial que cuelgan de las retiradas de AE100DB y AE100DF.
-
db03-mba-l-cc
-
2026-09-18 class re-measured (vehiculos grouped by dominio, all rows incl. borrado_en): PROD 0 dominios with >1 row, 0 with >1 live. DEV 2 dominios with 2 rows (DHU474 6621 marcada+6737 viva, FB444EP 6723 marcada+6726 viva), all origen_ingreso=app_dev test rows, 0 with >1 live (uq_vehiculos_dominio_active enforces it). AG045KB now 1 row in both bases. The 9 PROD pairs of 09-05 are gone; import path replaced by 486. DEV test residue is disposable per standing rule; not touched. Not exercised: FK refs of the 4 DEV rows, why the app created the marked+live pair.
bug
5w ago by wi-cli-venus
4w ago
2026-09-18 16:46