Previo a la entrega de un componente temporal, es aconsejable realizar una validación integral en lo que respecta a modificaciones a nivel base de datos y del diccionario de datos de Libertya realizadas en el componente.

La finalidad de dicha actividad es evitar incluir eventuales errores al incorporar este componente en la versión standard de Libertya (la BBDD “master” de desarrollo de LY, la cual es incluida como parte de los archivos entregados en cada release).

De esta manera evitamos entradas erróneas en el diccionario de datos que generen warnings al momento de aplicar actualizaciones de Libertya (que ya incluyen los cambios del componente temporal) sobre otra instancia.

Para comprender el paso a paso veamos el siguiente ejemplo. Se supone que se desarrolló un componente temporal denominado FOO, el cual posteriormente será parte de la versión standard de Libertya, versión LY CORE 17.05.

Los pasos para verificar el componente a nivel BBDD/Metadatos son los siguientes:

Esto simplemente implica realizar la exportación del componente utilizando la funcionalidad Exportar Componente desde el perfil System Administrator.

Al exportar, es posible que sea necesario habilitar el check Validar consistencia de la bitácora. Este check verifica para cada entrada del changelog si efectivamente existe la entrada en la BBDD. Por ejemplo, si el changelog indica la creación del campo FOO-AD_Field-10189311, se valida si efectivamente existe dicho registro en la tabla AD_Field.

Adicionalmente, se puede tildar también la entrada Deshabilitar entradas inexistentes. Este check desactivará las entradas del changelog que presentan inconsistencias entre la bitácora de cambios y la base de datos. Siguiendo el ejemplo anterior, si no se encuentra el registro FOO-AD_Field-10189311 en la tabla AD_Field, entonces se desactivan los registros de la tabla ad_changelog que conforman la información de generación del AD_Field en cuestión.

Estas situaciones pueden darse por ejemplo cuando se crea información en los metadatos y se registran automáticamente los cambios en la bitácora, pero luego se elimina dicha información. Si bien la eliminación queda registrada en la bitácora, es probable que registros relacionados son eliminados directamente en cascada (por constraints de Foreign Key) sin pasar por la bitácora, generándose un eventual desfazaje entre metadatos y base de datos. Un ejemplo es la creación de un Field y sus traducciones. La eliminación del Field implica la eliminación en cascada de las traducciones a nivel postgres, pero esto no queda registrado en la bitácora.

NOTA: Estas funcionalidades fueron implementadas a partir de la revision r1670, y sólo asisten en la búsqueda y detección de potenciales errores. Si bien en una primera iteración de la validación podría omitirse la utilización de estos checks, en caso de presentarse errores a lo largo de estos pasos probablemente en una segunda iteración sea necesario habilitarlos a fin de reducir el volumen de eventuales errores a presentarse.

Una vez exportado el componente FOO y armado el .jar de instalación, se procederá a instalarlo en una BBDD de libertya standard, indicando que se utilizará la funcionalidad de copia de changelog con mapeo a componente existente hacia el componente LY CORE 17.05 a fin de incorporar los cambios del componente FOO a la bitácora de cambios de la versión standard.

De esta manera, el componente LY CORE 17.05 de la versión standard contendrá todos los cambios de FOO como si hubieran sido desarrollados directamente sobre dicha BBDD.

La intención ahora es exportar LY CORE 17.05 completo (incluyendo las modificaciones de FOO llevadas a CORE), a fin de verificar posteriormente que efectivamente no haya errores al realizar una actualización desde LY CORE 16.04.

Se exporta el componente y se genera el jar de actualización correspondiente, siguiendo el ejemplo: org.libertya.core.upgrade_16.04_17.05.jar. Lógicamente será necesario ampliar el preinstall_from_16.04.sql alojado en los fuentes de LY según sea necesario a partir de las modificaciones incorporadas en el componente FOO, a fin de generar el preinstall.sql definitivo que quedará almacenado en el .jar de instalación.

Nuevamente, aquí se sugiere utilizar las funcionalidades Validar consistencia de la bitácora y Deshabilitar entradas inexistentes en caso de ser necesario.

Sobre una BBDD de Libertya 16.04, se prueba a realizar la actualización en cuestión, validando que no se presenten errores al momento de aplicar la misma.

En caso de errores, será necesario depurar/adaptar la bitácora de cambios del componente temporal FOO según las necesidades del caso, para realizar nuevamente las validaciones pertinentes.

En caso de errores, se deberá determinar primeramente el origen del mismo. Para esto será necesario revisar el log de instalación a fin de saber cuales son las entradas del changelog problemáticas.

Una vez determinado ésto, se debe proceder a realizar los ajustes necesarios, como por ejemplo deshabilitar dichas entradas o realizar modificaciones sobre las mismas.

A partir de la revisión r1766 la instalación de un componente incluye el changelogGroupID asociado a cada actividad de la bitácora, haciendo más sencilla la determinación del origen del error.

Por ejemplo:

WARNING: - Imposible eliminar - referencia inexistente en tabla. 
Referencia: (FOO2CORE-C_RetencionSchema-1010123) .
Tabla: C_RetencionSchema - changelogGroupID:1178479

Con esto sabemos que el changelogGroupID es el 1178479, el cual podemos observar en el postinstall.xml:

<changegroup changelogGroupID="1178479" 
operation="D" 
tableName="C_RetencionSchema" 
uid="FOO2CORE-C_RetencionSchema-1010123"/>

Esto permite realizar las modificaciones pertinentes sobre la tabla AD_Changelog del componente de desarrollo FOO, por ejemplo:

UPDATE AD_Changelog SET isactive = 'N' WHERE changelogGroup_ID = 1178479