Un soft-delete de la opcion 116 ALTA le haria entregar a SOTAMIT el string 'Alta (borrado)' en el campo estado del contrato externo congelado: 115 arreglo el conteo, no el string - eleccion de Elazar entre cuatro opciones
DECISION DE ELAZAR, NO DE UNA MIGRACION. El campo estado del contrato externo puede entregarle a SOTAMIT el string literal 'Alta (borrado)' si alguna vez se soft-deletea la opcion 116 ALTA. v_vehiculos_api_public hereda el CASE de sufijo desde v_vehiculos_detalle, y ese CASE le agrega ' (borrado)' a nombre_mostrable cuando la fila del catalogo esta borrada. POR QUE ES UN ITEM APARTE Y NO PARTE DE MOVILBA-115. El paquete de 115 (md5 b99d75db97cc965d74ef9ef02eb8fd94, aplicado en dev) ARREGLA EL CONTEO Y NO EL STRING. Cambio v_api_status.vehicles_activos para que cuente por estado_actual_id desde v_vehiculos_detalle en vez de comparar la etiqueta, asi que el conteo deja de irse a cero. Pero el campo de texto que viaja a SOTAMIT no se toco, a proposito: api_public es un contrato CONGELADO y no proyecta el id de estado, asi que arreglarlo es cambiarle a un integrador externo o el valor de un campo o la forma del payload. Eso no lo decide una migracion. ESTADO HOY: la opcion 116 ALTA esta viva, asi que el string que sale es 'Alta' y no hay incidente. Esto es exposicion, no defecto activo. Lo que lo hace real y no teorico es que el catalogo YA contiene una opcion soft-deleted del mismo grupo - la 118 TRANSFERENCIA, borrada el 2025-10-13 - o sea que la operacion que dispara esto es una operacion normal de catalogo que ya ocurrio una vez, no un caso raro. LAS OPCIONES, y ninguna es de un carril: a) Dejarlo. Aceptar que un soft-delete de catalogo le cambia un valor de campo a SOTAMIT y confiar en no borrar la 116. b) Sacarle el sufijo a la rama de api_public y dejarlo en las superficies internas. Cambia el valor entregado solo en el caso borrado; la forma del payload no se mueve. c) Agregarle a api_public una columna con el id de estado y que SOTAMIT compare por id. Es lo correcto a largo plazo y ROMPE la forma del contrato congelado. d) Bloquear el soft-delete de las opciones que consume el contrato externo. Mueve el problema al catalogo en vez de a la vista. NO EMPEZAR NINGUNA SIN QUE ELAZAR ELIJA. Es de cara externa y el limite duro de GCABA aplica: cualquier opcion que necesite que SOTAMIT cambie algo de su lado hay que descartarla, porque no hay via para pedirselo. Origen: MOVILBA-115, escrito en el header del paquete por coder02-mba-l-cc porque el item se lee como cerrado sin esto.
Activity
-
MEDIDO EN PROD POR db03-mba-l-ca, 2026-08-21 12:06 ART. Gate de entorno: inet_server_addr()=10.78.42.168 + current_database()=movilba (las dos, no solo el nombre). ALCANCE DEL BARRIDO: las 20 columnas de tablas base con FK a opciones, mas la columna historica sin FK vehiculos_datos_colectivos_archive.estado_id (la unica columna archivada que semanticamente guarda vehiculo/estado). CONTEO POR COLUMNA (total / fila propia viva / fila propia borrada logicamente): vehiculos_datos_colectivos.estado_id : 116 ALTA 1977/1600/377 · 117 BAJA 417/138/279 vehiculo_historial.estado_id : 116 ALTA 1604/1602/2 vehiculos_datos_colectivos_archive.estado_id (historico, no filas vivas de negocio): 116=18 · 117=4 Las otras 17 columnas con FK: CERO referencias a las cuatro opciones. 118 TRANSFERENCIA = 0 y 119 MANTENIMIENTO = 0 en todos lados. LA RESPUESTA A LA PREGUNTA QUE SE HIZO: NO existe hoy ningun caso de opcion-muerta x fila-viva. Ninguna fila de negocio, ni viva ni borrada, referencia la opcion muerta 118. CONTROL POSITIVO (sin esto el cero no dice nada): existen valores distintos de 118 en cada columna de estado relevante - vdc 2394, historial 1604, archive 22 - o sea que los predicados de 118 SI tuvieron entrada. CONSECUENCIA PARA LA DECISION: el sufijo ' (borrado)' de 118 no es alcanzable hoy por ningun ID de estado guardado. El riesgo de 118 no es el dato actual sino la REUTILIZACION futura o una referencia muerta nueva. La eleccion entre las cuatro opciones sigue abierta, pero se decide sobre riesgo futuro, no sobre un sintoma vivo.
-
Elazar 2026-08-21: el item no tiene objeto. Medicion de db03 en prod (12:06): la opcion 118 TRANSFERENCIA tiene CERO referencias en las 20 columnas con FK a opciones y en la columna historica del archive, con control positivo (existen valores distintos de 118 en cada columna: vdc 2394, historial 1604, archive 22). Y como 118 esta borrada logicamente no se puede elegir, asi que tampoco puede aparecer una referencia nueva: el cero no es una foto, es el techo. El framing de 'riesgo de reutilizacion futura' que yo habia escrito era el error - no hay camino por el que una fila nueva tome 118. Sin filas hoy y sin filas posibles manana, no hay nada que decidir sobre el sufijo ' (borrado)' de 118.
-
CORRECCION al cuerpo del cancel anterior, que aplica el argumento a la opcion equivocada. El item NO es sobre 118 TRANSFERENCIA: el titulo dice 116 ALTA, que esta VIVA y tiene 3581 referencias (vdc 1977 + historial 1604). El razonamiento 'esta borrada, no puede aparecer una fila nueva' vale para 118 y solo para 118. Lo que 120 planteaba es la hipotesis inversa: que alguien soft-deletee 116 en el futuro, y entonces el contrato externo congelado de SOTAMIT reciba 'Alta (borrado)' en el campo estado. 115 arreglo los conteos, no el string del contrato. Queda cancelado a la espera de la palabra de Elazar sobre esta premisa distinta.
-
SUPERSEDIDO POR MOVILBA-123. Elazar, 08-21: 120 preguntaba la pregunta chica (una opcion, un consumidor, una hipotesis que nadie iba a ejecutar). La real es generica - que le pasa a la app cuando se borra logicamente CUALQUIER opcion del catalogo, en todas las superficies, no solo el contrato de SOTAMIT.