Herramientas de usuario

Herramientas del sitio


plugins:validacionescomponente

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
plugins:validacionescomponente [2017/02/02 12:40]
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**, se valida si efectivamente existe dicho registro en la tabla **AD_Field**. 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**.
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.  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. 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 un a segunda iteración sea necesario tildarlos a fin de reducir el volumen de eventuales errores a presentarse.+**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.
  
  
 ==== 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, se procederá a instalarlo en una BBDD de libertya standard, indicando que se utilizará la funcionalidad de [[plugins:copiadechangelog|copia de changelog]] hacia **LY CORE 17.05** a fin de incorporar los cambios del componente a la bitácora de cambios de la versión standard.+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 [[plugins:copiadechangelog#instalacion_con_copia_de_changelog_con_mapeo_a_componente_existente|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. 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.
Línea 37: Línea 37:
 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. 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**.+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. Nuevamente, aquí se sugiere utilizar las funcionalidades **Validar consistencia de la bitácora** y **Deshabilitar entradas inexistentes** en caso de ser necesario.
plugins/validacionescomponente.1486039254.txt.gz · Última modificación: 2021/04/30 19:21 (editor externo)