Historical lines 23, 90 and 99 resolve through retired catalog rows
El libro RUTAP 2026-09-03-1049 trae 31 valores distintos de Linea (incluido '0'). PROD tabla lineas tiene 28 filas vivas. Faltan 23, 90 y 99. MEDICION en el libro, solo filas con Nro_dominio no vacio: linea 23: 18 filas, todas CERRADAS, 9 dominios, 0 con fila abierta linea 90: 41 filas, todas CERRADAS, 41 dominios, 0 con fila abierta linea 99: 116 filas, todas CERRADAS, 43 dominios, 0 con fila abierta POR QUE NO ES UN DEFECTO DE ESTADO ACTUAL: ninguna de las tres tiene una sola fila abierta en el libro, asi que ningun vehiculo esta hoy en servicio en ellas. La superficie de estado corriente no pierde nada. POR QUE IGUAL IMPORTA: son 175 periodos CERRADOS que referencian una linea que MovilBA no puede nombrar. Cuando aterrice el historial ancho (MOVILBA-125 / 155) esos periodos necesitan un linea_id y no lo hay. Se resuelve creando las tres filas ANTES del import de historia, no despues. CONTROL POSITIVO: de las 31 lineas citadas en la hoja 'Normativa Lineas' del tracker, 27 resuelven contra lineas por btrim(numero_linea) - el join funciona. Las que no resuelven son 6, 23, 90 y 99. La 6 tampoco esta en el libro y su propia fila del tracker dice 'sin anexo linea caducada', asi que su ausencia es coherente; 23, 90 y 99 SI estan en el libro. NO EJERCITADO: no mire DEV, no mire si algun v_ui_* filtra por linea de un modo que rompa, y no propuse ningun INSERT - toda escritura necesita GO.
Activity
-
db03-mba-l-ca
-
1
-
Import/reconciliation classification (db02 2026-09-03): lines 90 and 151 belong to soft-deleted M.O.D.O.; line 23 belongs to soft-deleted Transportes Rio Grande. These lines and entities are one retirement event. Historical loader lookup resolves their existing soft-deleted catalog rows without undeleting/recreating anything; do not insert bare replacement lineas.
-
db03-mba-l-cc
-
db02-mba-l-cc
-
db02-mba-l-cc, 2026-09-12: clasificacion para la propuesta agrupada (detalle en MOVILBA-190). NO ES UNA REPARACION DEL LOADER: el loader no crea filas en la tabla lineas. Son tres filas de CATALOGO que faltan en PROD, y por lo tanto caen bajo la regla de catalogos -una fila esta viva o no esta- y bajo la regla de censar las BORRADAS antes de crear, porque la que falta suele estar ahi soft-deleteada con vehiculos encima. Se mide eso primero y recien despues se propone el INSERT. Grupo propio, GO propio.
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:01 ART — SELECT-only public.lineas check: DEV movilba_dev and PROD movilba each have one catalog row for linea 23, 90 and 99, but zero live rows for each (borrado_en IS NOT NULL). The historical lookup behavior of the installed importer was not exercised; no status change. Do not insert bare replacements based on the old missing-row wording.
-
coder03-mba-l-cc 2026-10-01 17:55: re-measured in PROD and DEV. The title's premise is wrong as installed: the three lines are NOT missing. public.lineas holds 23 with id 23, 90 with id 85 and 99 with id 11 in both bases, identically, and all three are SOFT-DELETED, not absent. The 175 book history rows the item counts also resolve their foreign key - raw_linea 23 with linea_id 23 in 18 rows, 90 with 85 in 41 rows and 99 with 11 in 116 rows, 175 in total, which is the item's own number. So the loader resolved every one of them and there is nothing unresolved to repair. The question worth asking instead was whether a soft-deleted line loses its label on a surface, and the answer is no. Of the 25 installed views that read lineas, the four that publish vehicle and history data - v_vehiculo_historial, v_vehiculos_export, v_vehiculos_detalle and v_vehiculos_list - do NOT filter lineas.borrado_en, so a retired line still renders its number on those surfaces, which is what a closed period from the book needs. The pickers do the opposite and also correctly: v_ui_lineas and v_lineas both return 28 rows, the live count, and neither returns id 23, 85 or 11, so no form offers a retired line. The two behaviours together are coherent and are what the data needs. Context worth keeping separately: 30 of the 58 rows in public.lineas are soft-deleted, more than half the table. That is the marking pattern Elazar rejected in MOVILBA-378 for small catalogs, so whether lineas falls under that policy is a question for 378, not for this item. Recommend closing as not reproducing. UNEXERCISED: I checked the filter presence in the four publishing views by their installed definitions, not the other 21 views one by one, and I rendered no screen or PDF - this is a database-level statement about which views filter the soft delete, not a visual confirmation that the line number appears on the vehicle page. Status left to db04-mba-l-ca, whose item it is.
-
db04-mba-l-ca 2026-10-01 17:58 ART. Closed on coder03-mba-l-cc's SELECT-only installed-object measurement recorded on this item at 17:55 ART in both PROD movilba and DEV movilba_dev: public.lineas has 23/id23, 90/id85, and 99/id11 in both bases, all soft-deleted rather than missing. Current normalized history resolves all 175 cited source rows to those exact linea_id values (18+41+116). Installed publishing views v_vehiculo_historial, v_vehiculos_export, v_vehiculos_detalle and v_vehiculos_list do not filter lineas.borrado_en, so their historical labels remain available; picker views v_ui_lineas and v_lineas return 28 live lines and exclude all three retired IDs. Therefore the asserted missing FK/catalog-repair task no longer exists, and no INSERT or undelete is justified. Scope: DB views and history only; no page/PDF render and no census of the other 21 dependent views. The wider soft-delete policy for 30/58 lineas belongs to MOVILBA-378, not this item. No code or DB write.
-
Historical lines 23, 90 and 99 resolve through retired catalog rows