Muestra las diferencias entre dos versiones de la página.
plugins:copiadechangelog [2016/09/23 19:54] mcap |
plugins:copiadechangelog [2021/04/30 19:19] |
||
---|---|---|---|
Línea 1: | Línea 1: | ||
- | ====== Funcionalidad de copia de Changelog en instalación ====== | ||
- | Es posible " | ||
- | |||
- | **MUCHO MUY IMPORTANTE**: | ||
- | |||
- | **Alternativas de instalación**: | ||
- | |||
- | - **Instalación tradicional**: | ||
- | - **Instalación con copia de changelog**: | ||
- | - **Instalación con copia de changelog con mapeo a componente existente**: | ||
- | |||
- | Para comprender más en detalle este tema, se verá a continuación un ejemplo. | ||
- | |||
- | ===== Instalación tradicional ===== | ||
- | |||
- | Aquí no es necesario realizar ninguna acción adicional, dado que es el caso por defecto de instalación. | ||
- | |||
- | ===== Instalación con copia de changelog ===== | ||
- | |||
- | En este caso instalaremos **FOO**, registrando como un nuevo componente, se impactarán los cambios en base de datos, y se incorporarán los mismos también al changelog; utilizando las referencias al componente **FOO** en todos los casos. | ||
- | |||
- | Para lograr este tipo de instalación es necesario incorporar la siguiente linea en el archivo **manifest.properties** del componente: | ||
- | |||
- | COPYTOCHANGELOG = Y | ||
- | |||
- | ===== Instalación con copia de changelog con mapeo a componente existente ===== | ||
- | |||
- | En este caso no registraremos a FOO como un nuevo componente, sino que el mismo deberá ser mapeado (en todo sentido) a un componente ya existente en nuestra base de datos. | ||
- | |||
- | Por ejemplo, suponemos que queremos incorporar FOO al CORE de Libertya como un desarrollo de éste. | ||
- | |||
- | COPYTOCHANGELOG = Y | ||
- | MAPTOCOMPONENTUID = CORE-AD_Component-1010001 | ||
- | MAPTOCOMPONENTVERSIONUID = CORE-AD_ComponentVersion-1010024 | ||
- | | ||
- | Además de especificar la copia al changelog, se indican dos valores adicionales: | ||
- | |||
- | ==== Mapeo de UIDs ==== | ||
- | |||
- | Un aspecto de especial interés es el de los AD_ComponentObjectUIDs. | ||
- | |||
- | * Se determina la operación a realizar (**I**nsert, | ||
- | * Si la operación es **I**, se genera un nuevo UID utilizando ambos prefijos y un timestamp desambiguador (guardamos y mapeamos la nómina de registros creados en esta instalación). Por ejemplo: | ||
- | * **FOO-AD_Column-1348734** se mapea a **FOO2CORE-AD_Column-1348734_20120321111740** | ||
- | * Se genera una map en memoria que almacena: Clave: viejo UID, Valor: nuevo UID. | ||
- | * Si la operación es **M** o **D** se busca primeramente el UID del registro a modificar/ | ||
- | * Para las referencias a otras tablas también se busca primeramente en la map, a fin de respetar el mapeo en todos los casos. | ||
- | |||
- | **Nota**: Aunque el UID se podría mapear a CORE-AD_Column-xxxxxxx (donde xxxxxxx es el AD_Column_ID del registro que se está insertando, para esto se requiere complejidad adicional de procesamiento post-persistencia), | ||
- | |||
- | |||
- | ==== Consideraciones adicionales en instalación con mapeo ==== | ||
- | |||
- | Hay que tener especial cuidado si se cuenta con un proceso post-install ad-hoc, el cual realiza modificaciones basadas en UIDs. Se recomienda en estos casos utilizar otra clave de búsqueda (dado que los UIDs mapeados poseen el timestamp para desambiguación). | ||
- | |||
- | |||
- | TODO INTERNO: Al instalar con mapeo el UID crece considerablemente. | ||
- | |||
- | - Generar un UID temporal y ponerlo en la map al insertar | ||
- | - Luego, en el metodo **handleSuccess()** de **PluginXMLUpdater**, | ||
- | - Actualizar la map con el nuevo UID | ||
- | |||
- | /** | ||
- | * En caso de ser necesario, ejecutar acciones adicionales luego del | ||
- | * exito en la ejecucion de la sentencia SQL generada e impactada en BBDD | ||
- | * Este metodo puede ser redefinido por subclases según sea necesario | ||
- | */ | ||
- | protected void handleSuccess(String sentence, ChangeGroup changeGroup) throws Exception | ||
- | { | ||
- | // Implemented by subclass | ||
- | } | ||
- | | ||
- | ==== Limitaciones en instalación con mapeo ==== | ||
- | |||
- | **MUY IMPORTANTE**: | ||
- | |||
- | Ejemplo: | ||
- | |||
- | - Instalación 1 | ||
- | - Se inserta una columna. UID original: **FOO-AD_Column-1348734**, | ||
- | - No se descarta el componente temporal y se continua con su desarrollo | ||
- | - Se modifica la columna con UID **FOO-AD_Column-1348734** | ||
- | - Instalación 2 | ||
- | - Se intenta modificar el registro con UID **FOO-AD_Column-1348734**, | ||
- | |||
- | __Por lo tanto__: **Luego de una instalación con mapeo, la manera correcta de proceder es crear un nuevo componente temporal, tomando como punto de desarrollo inicial la base de datos donde se instaló el anterior componente temporal**. | ||
- | |||
- | ====== Operatoria en instalación con copia al changelog y mapeo ====== | ||
- | |||
- | Los pasos para instalación de un componente y copia al changelog con mapeo son los siguientes: | ||
- | |||
- | - Tomar el .jar exportado de la bbdd origen | ||
- | - Modificar el properties.manifest, | ||
- | - Instalar el componente | ||
- | - Verificar la correctitud en las tablas y el changelog | ||
- | - Copiar el preinstall.sql del .jar original al preinstall.sql del componente destino |