Muestra las diferencias entre dos versiones de la página.
Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
plugins:validacionescomponente [2017/02/02 12:02] fcristina |
plugins:validacionescomponente [2021/04/30 19:19] (actual) |
||
---|---|---|---|
Línea 16: | Línea 16: | ||
- | Esto simplemente implica realizar la exportación del componente utilizando la funcionalidad **Exportar Componente**. | + | 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**, | 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**, | ||
Línea 24: | Línea 24: | ||
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. | 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. | ||
- | **NOTA:** Estas funcionalidades | + | **NOTA:** Estas funcionalidades |
==== PASO 2: Instalar en una copia de la BBDD libertya standard, incorporando al changelog ==== | ==== PASO 2: Instalar en una copia de la BBDD libertya standard, incorporando al changelog ==== | ||
- | Una vez exportado el componente **FOO** y armado el .jar de instalación, | + | Una vez exportado el componente **FOO** y armado el .jar de instalación, |
- | De esta manera, la versión standard contendrá todos los cambios de **FOO** como si hubieran sido desarrollados directamente sobre dicha BBDD. | + | De esta manera, |
==== PASO 3: Exportar el changelog de LY CORE que ahora incluyen los cambios de FOO ==== | ==== PASO 3: Exportar el changelog de LY CORE que ahora incluyen los cambios de FOO ==== | ||
- | La intención ahora es exportar **LY CORE 17.05** completo (incluyendo **FOO** | + | La intención ahora es exportar **LY CORE 17.05** completo (incluyendo |
- | Se exporta el componente y se genera el jar de actualización correspondiente, | + | Se exporta el componente y se genera el jar de actualización correspondiente, |
Nuevamente, aquí se sugiere utilizar las funcionalidades **Validar consistencia de la bitácora** y **Deshabilitar entradas inexistentes** en caso de ser necesario. | Nuevamente, aquí se sugiere utilizar las funcionalidades **Validar consistencia de la bitácora** y **Deshabilitar entradas inexistentes** en caso de ser necesario. | ||
Línea 43: | Línea 43: | ||
==== PASO 4: Prueba de instalación ==== | ==== PASO 4: Prueba de instalación ==== | ||
- | 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. | + | 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/ | + | En caso de errores, será necesario depurar/ |
+ | ===== En caso de error ===== | ||
+ | En caso de errores, se deberá determinar primeramente el origen del mismo. | ||
+ | |||
+ | 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: | ||
+ | |||
+ | Con esto sabemos que el changelogGroupID es el 1178479, el cual podemos observar en el **postinstall.xml**: | ||
+ | |||
+ | < | ||
+ | operation=" | ||
+ | tableName=" | ||
+ | uid=" | ||
+ | | ||
+ | Esto permite realizar las modificaciones pertinentes sobre la tabla AD_Changelog del componente de desarrollo FOO, por ejemplo: | ||
+ | |||
+ | UPDATE AD_Changelog SET isactive = ' |