uq_personas_cuit_cuil_activo existe en PROD y no en DEV: DEV acepta CUITs duplicados que PROD rechaza
MEDIDO por db02 el 2026-09-18 en el diff DEV/PROD de indices. Contesta la fila 5 del censo 479 ('portar a DEV?') con el hecho que faltaba: el indice existe SOLO en PROD. public.personas :: uq_personas_cuit_cuil_activo - existe en PROD, NO existe en DEV. Es el unico indice solo-en-PROD de toda la corrida (215 indices en DEV, 212 en PROD; el unico solo-en-DEV es ux_carrocerias_fabricante_modelo, que es MOVILBA-501). Por el nombre es un unique parcial sobre cuit/cuil de personas activas, o sea una proteccion de identidad: impide dos personas activas con el mismo CUIT. DIRECCION: PROD -> DEV, sin ambiguedad. Es una proteccion, y la base que no la tiene es la permisiva; misma logica que MOVILBA-493 y 501 pero al reves de lado. Mientras no este, DEV acepta duplicados de CUIT que PROD rechaza, y una prueba de alta de persona en DEV no dice nada sobre PROD. ANTES DE CREARLO: contar en DEV los grupos que lo violarian, con la definicion EXACTA de PROD (pg_get_indexdef, no reconstruida de memoria - incluye el predicado parcial, que es donde esta el significado de 'activo'). Si DEV tiene duplicados, hay que limpiarlos primero o el CREATE falla, y limpiar personas en DEV alcanza datos que pudo crear un usuario, asi que se mira origen antes de borrar. Correr ademas la consulta sombra: contar con y sin el predicado de actividad, porque 'activo' es justamente el predicado que puede estar escondiendo el duplicado. Prioridad baja: DEV es descartable y nadie esta bloqueado. Es deuda de convergencia, no un defecto vivo.
Activity
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:00 ART — SELECT-only installed-index check: DEV movilba_dev has no uq_personas_cuit_cuil_activo; PROD movilba has UNIQUE public.personas(cuit_cuil) WHERE borrado_en IS NULL and cuit_cuil is nonempty. The DEV half remains unverified/uninstalled; no status change or DB write.
-
db03-mba-l-cc / db
-
db03 2026-10-08: applied, per coder03's explicit scope-in-without-GO call under the parity rule. Closing. PRECONDITION RE-MEASURED FRESH (not trusting the 09-18 note's numbers unchanged): exact-predicate duplicate count in DEV today - 1 group, cuit_cuil '20-42118402-0', personas.id {91, 177}. Shadow count without the activity predicate - 3 groups total (the other two, {81,22} and {82,83,30}, are already fully soft-deleted and were never going to block the partial index - only the 91/177 pair had a live member on both sides). Persona 177 confirmed QA fixture, not a real duplicate of 91: apellido 'Galati Test', no DNI, creado_por = CUIT of persona 91 without punctuation. FK check (the one explicit gap the 09-18 note and MOVILBA-537's 09-23 blackboard both left unmeasured): chofer_historial.id=4 references it, observaciones column literally reads 'Persona creada para test', creado_por same test CUIT; personas_datos_chofer.id=10 references it too, empty row (no fecha_inicio_actividad, no ambito). Both are fixtures of the SAME test session, not external real data, and a soft-delete never engages a FK constraint regardless (UPDATE borrado_en, not DELETE). APPLIED to DEV only (2026-10-08 ~11:57 ART): UPDATE personas SET borrado_en=now() WHERE id=177; then CREATE UNIQUE INDEX uq_personas_cuit_cuil_activo ON public.personas USING btree (cuit_cuil) WHERE borrado_en IS NULL AND cuit_cuil <> ''. Verified: DEV and PROD's pg_get_indexdef now md5-identical (66c9f18a6ab6167cf8ecaaacc0a8c403, both sides). Migration doc: docs/migrations/2026-10-08-movilba-503-uq-personas-cuit-cuil-activo-DEV.sql (untracked, needs coder03's commit). Persona 91 untouched. No other persona rows touched. PROD not written (already had the index; this was DEV-only parity). This also clears the precondition MOVILBA-537 item (3) flagged as unmeasured - same pair, same index, now done as part of this ticket rather than 537 (537's own note updated separately this session to point here rather than duplicate the finding).
-
db03: applied to DEV (soft-delete QA-fixture persona 177, create uq_personas_cuit_cuil_activo matching PROD byte-for-byte). Migration doc added, needs commit. See note.