Actualización del Sistema de Elecciones

La actualización del Sistema de Elecciones debe realizarse con una ventana de mantenimiento, respaldo previo de base de datos y despliegue coordinado de base, artefactos y configuración. Para v3.0, los scripts intermedios posteriores a v2.4 fueron consolidados en release-files/3.0/v3.0_script.sql.


Alcance de la actualización a v3.0

Antes de ejecutar scripts, confirme la versión instalada y aplique todos los scripts pendientes en orden. No omita versiones intermedias.

  • Si la base ya está en v2.4, aplique únicamente release-files/3.0/v3.0_script.sql.
  • Si la base está en v2.3.1, aplique release-files/2.4/v2.4_ddl_script.sql, luego release-files/2.4/v2.4_data_script.sql y finalmente release-files/3.0/v3.0_script.sql.
  • Si la base está en v2.3, aplique primero release-files/2.3.1/v2.3.1_script.sql y después la cadena de v2.4 y v3.0.
  • Si la base es anterior a v2.3, revise los Release notes y aplique todos los scripts desde su versión actual hasta v3.0.

Preparación previa

  • Ejecute un respaldo completo de la base PostgreSQL antes de modificar datos o estructura.
  • Conserve una copia de la versión de aplicación actualmente desplegada para poder volver atrás si la actualización no finaliza correctamente.
  • Prepare los artefactos o la imagen Docker de la versión a desplegar antes de iniciar la ventana de actualización.
  • Ejecute los scripts con una conexión que corte ante el primer error, por ejemplo usando psql -v ON_ERROR_STOP=1.

Controles de datos antes de v3.0

El script de v3.0 crea índices únicos por elección sobre ORGID normalizado en organization y uservoter. Si existen duplicados o votantes sin ORGID recuperable desde el mail, el script aborta con error. Ejecute estos controles y corrija los datos antes de aplicar el script.

Organizaciones con ORGID duplicado dentro de una misma elección:

SELECT election_id, upper(btrim(orgid)) AS normalized_orgid, COUNT(*) AS total
FROM public.organization
GROUP BY election_id, upper(btrim(orgid))
HAVING COUNT(*) > 1;

Votantes cuyo ORGID no puede recuperarse desde el mail:

SELECT uservoter_id, election_id, mail, orgid
FROM public.uservoter
WHERE (orgid IS NULL OR btrim(orgid) = '')
  AND (mail IS NULL OR btrim(mail) = '');

Votantes que quedarían con ORGID duplicado después del backfill desde mail:

WITH normalized AS (
    SELECT
        election_id,
        upper(btrim(CASE
            WHEN orgid IS NULL OR btrim(orgid) = '' THEN mail
            ELSE orgid
        END)) AS normalized_orgid
    FROM public.uservoter
    WHERE (orgid IS NOT NULL AND btrim(orgid) != '')
       OR (mail IS NOT NULL AND btrim(mail) != '')
)
SELECT election_id, normalized_orgid, COUNT(*) AS total
FROM normalized
GROUP BY election_id, normalized_orgid
HAVING COUNT(*) > 1;

Ejecución de scripts

Ejecute los scripts desde el directorio raíz del repositorio. Ajuste los datos de conexión de psql según su ambiente.

Ejemplo para una base que ya está en v2.4:

psql -v ON_ERROR_STOP=1 -d <database> -f release-files/3.0/v3.0_script.sql

Ejemplo para una base que está en v2.3:

psql -v ON_ERROR_STOP=1 -d <database> -f release-files/2.3.1/v2.3.1_script.sql
psql -v ON_ERROR_STOP=1 -d <database> -f release-files/2.4/v2.4_ddl_script.sql
psql -v ON_ERROR_STOP=1 -d <database> -f release-files/2.4/v2.4_data_script.sql
psql -v ON_ERROR_STOP=1 -d <database> -f release-files/3.0/v3.0_script.sql

Validación posterior de base

  • Verifique que los scripts terminaron sin errores y que no quedaron transacciones interrumpidas.
  • Confirme que la aplicación puede iniciar y conectarse al datasource java:jboss/datasources/elections-ds.
  • Valide flujos operativos básicos: login administrativo, listado de elecciones, acceso a una elección existente y disponibilidad del servicio web si está habilitado en su instalación.

El repositorio incluye el validador python3 release-files/validate_new_release_chain.py para comprobar, en un PostgreSQL temporal local, que la referencia nueva cierra contra elections_schema_old más v2.4 y v3.0. Este validador requiere binarios PostgreSQL como psql, initdb, pg_ctl y pg_dump disponibles en el PATH.


Empaquetado y publicación

La versión actual compila con Java 17 y se despliega sobre WildFly 34. El repositorio contiene tres módulos Maven: elections-ejb, elections-admin-web y elections-services.

Para despliegue manual en WildFly, compile los módulos y publique los artefactos generados en el directorio standalone/deployments de la instalación:

  • elections-ejb/target/elections-ejb-1.0.jar
  • elections-admin-web/target/elections.war
  • elections-services/target/elections-ws.war
  • wildfly/deployments/pai-auth-ws-client-1.5.1.jar, si su instalación usa autenticación contra PAI.

Para despliegue Docker, el Dockerfile actual parte de wildfly:34.0.0.Final-jdk17, copia los artefactos anteriores, los módulos de wildfly/modules y la configuración wildfly/configuration/standalone.xml. El docker-compose.yml usa la imagen configurada para el ambiente, expone el puerto 8098:8080 y carga variables desde .env.

Después de publicar, reinicie la aplicación y revise logs de WildFly antes de habilitar el uso normal del sistema.