Estamos trabajando en actualizar de la 3.21.1 a la 3.23.0 y no encontramos con varios cambios en la estructura de datos, por ahora encontramos que ‘usuario’ de mdp_personas pasa a ser e_mail, en sga_preinscripcion hay varias columnas que se eliminan y otras que se crean.
La consulta es, en principio, si están documentados en algún lado los cambios en modelo y otros breaking changes que introduce cada versión.
Por otra parte, quería saber cuál sería la forma que recomiendan de reflejar estos cambios en la auditoría, ya sea en las tablas como las funciones.
Para el 1er punto que nos haces llegar en relacion a los cambios de estructuras de datos , te pasamos las Principales novedades técnicas que hubieron de la version .3.21.1 a la 3.23.0 .. lo pueden ver en el siguietne link:
En relacion al 2do punto: "quería saber cuál sería la forma que recomiendan de reflejar estos cambios en la auditoría, ya sea en las tablas como las funciones." → nos podrian amplair lo que precisan , darnos mas detalle del mismo si , asi podemos comprender mejor lo que precisan. Es decir ¿ para que usan la auditoria ? ¿ con que fin lo utilizarian? etc .
Se ve que no se interpretó bien. Yo me refiero a notas de la versión con aclaraciones puntuales sobre cambios disruptivos. El diff no es muy útil ya que son miles de líneas fuera de contexto.
Respecto al segundo punto, me estoy refiriendo al esquema de auditoría del esquema negocio, lo usamos con fines de auditoría por lo cual mantenemos todo el historial.
En relacion al primer punto entonces desde nuestra documentacion tecnica pueden ver los avances y novedades tecnicas de version a version mediante el siguiente link .
En relacion al otro tema desde el SIU no tenemos recomendaciones al respecto al no estar en la realidad del día a día de las universidades, seria buenisimo que consulten la experiencia de otras universidades y los posibles consejos que podrian brindarles en relacion a este tema.
Respecto al primer punto, revisé el link de novedades técnicas, siempre lo revisamos al momento de actualizar, pero no encontré el tipo de información que buscamos: cambios disruptivos a nivel técnico que requieran acción de nuestra parte al actualizar. Esto incluye, por ejemplo, cambios en estructura de tablas (altas, bajas o renombres de columnas), pero también podría tratarse de cambios de comportamiento en funciones, procesos batch, configuraciones, o cualquier otro breaking change que no sea evidente simplemente mirando las novedades técnicas. Es posible que este tipo de cambios se documente en algún otro lado, o no se relevan actualmente de forma centralizada?
Respecto a la auditoría, voy a ser más específico: cuando una nueva versión trae cambios estructurales como los mencionados arriba, cuál es el procedimiento recomendado para que la auditoría quede consistente con la nueva estructura?
Puntualmente, hay que volver a correr guarani crear_auditoria después de aplicar los diferenciales? Si es así, se preservarían los datos de auditoría ya existentes?
Un ejemplo para ambos casos es el renombrado de las tablas sga_requisitos_ingreso* que pasaron a llamarse sga_requisitos_propuestas*. Tenemos personalizaciones relacionadas a esas tables y respecto a la auditoría, aunque se genere la nueva auditoría, la misma quedaría partida en dos tablas distintas para cada tabla renombrada si no se corre un script de migración.
Respecto a la auditoría, se migra automáticamente al ejecutar el comando ‘./guarani migrar_base’ (paso 3.8 del instructivo de actualización).
Algunas cuestiones sobre la auditoría:
No existe un comando para actualizar la auditoría. Es el mismo ./guarani crear_auditoria que cuando ya existe la actualiza y NO borra los datos.
Si la auditoría ya existe, para actualizarla es necesario agregar el parámetro --force 1 para forzar la eliminación de los triggers que ya existen. Caso contrario va a dar error al querer recrearlos.
El comando no muestra los errores en consola, se visualizan sólo en el log de comandos. El único indicio es que si termina correctamente muestra “OK”.