Orden de lectura del export de vehiculos vive DENTRO de v_vehiculos_export (aplicado en prod 2026-08-19)
db-mba-l-cc: aplicado en PROD 2026-08-19 con GO de Elazar ('go'), archivo docs/migrations/2026-08-19-export-order-by-en-la-vista.sql (md5 057995a19a0a208cee2755b7cb063e4e). ORDER BY e.nombre, l.numero_linea, vdc.interno, (vdc.fecha_vigencia_hasta IS NOT NULL), v.dominio. Antes era vehiculo_id DESC en codigo = orden de insercion del importador: 131 de las primeras 200 filas eran bajas. coder saco el orderBy() del codigo en v5.3.213, o sea la lectura quedo PELADA y el orden llega al archivo. Ejercitado de punta a punta: curl con api-key a app.movilba.com/api/v1/exports/vehiculos?format=csv -> 200, 576639 bytes, 1736 filas, 134 bajas, abre en 17 DE AGOSTO S.A. / 26 / 201. Metricas del apply: CORV 18.9ms, ventana total 206.4ms, 1736 filas con 0 diferencias comparadas en AMBAS direcciones, 0 pares fuera de secuencia. QUEDA SIN EJERCITAR: el boton Descargar por browser (sesion NextAuth, no api-key) - solo Elazar puede probarlo. EL ORDEN ES LOAD-BEARING: si un consumidor futuro agrega join/where/orderBy propio, el planner descarta el ORDER BY de la vista SIN error y devuelve orden equivocado en silencio.
Activity
-
Aplicado y verificado end-to-end contra el archivo real de prod. Unico tramo abierto (boton por browser) queda fuera de este WI: es camino de UI y lo prueba Elazar.
-
EJERCITADO DE PUNTA A PUNTA CONTRA EL ARTEFACTO REAL (db-mba-l-cc, 2026-08-20 00:13), no leyendo la vista: curl con la api-key unificada a https://app.movilba.com/api/v1/exports/vehiculos?format=csv -> HTTP 200, 576.639 bytes, 1736 filas de datos, 134 bajas. El orden de la vista LLEGA al archivo. primera fila: 17 DE AGOSTO S.A. / 26 / 201 / PIK914 ultima fila: VUELTA DE ROCHA S.A.T.C.I. / 64 / 59 / AI095HF Confirma que v5.3.213 saco el orderBy(desc(vehiculoId)) de src/lib/exports/vehiculos.ts:125 y el consumidor ya no pisa la vista. Falta SOLO el boton por browser (sesion NextAuth), que ningun agente puede ejercitar. SALVEDAD DE COLLATION, medida en el archivo real, NO es defecto y no hay que arreglarla salvo que Eugenia lo pida: fila 747 LINEA 102 - SARGENTO CABRAL S.A. (con I acentuada) fila 748 LINEA DE MICROOMNIBUS 47 SA (sin acento) en_US.UTF-8 ordena la I acentuada junto a la I comun; una verificacion en Python ordena por codepoint, donde LINEA < LI-acentuada. La inversion la introduce la medicion, no la base: por collation de la base el archivo esta 100% ordenado, 0 pares fuera de secuencia, igual que dio el gate al aplicar. Si Eugenia lo reporta como raro, el arreglo es ordenar por unaccent(entidad) - la extension unaccent YA esta instalada, es una linea en la vista y no una migracion nueva. El criterio lo cierra Elazar con ella.