| Ambos lados, revisión anterior
Revisión previa
Próxima revisión
|
Revisión previa
|
plugins:copiadechangelog [2020/02/21 12:37]
fcristina |
plugins:copiadechangelog [2021/04/30 19:19] (actual)
|
| ====== Funcionalidad de copia de Changelog en instalación ====== | ====== Funcionalidad de copia de Changelog en instalación ====== |
| |
| ^ MUY IMPORTANTE: La información aquí detallada refiere a la metodología original, previo a la implementación de la metodología de micro componentes (r2819), la cual si bien es mayormente similar, difiere en cuanto al mapeo de UIDs dado que ya no es necesario mapear los AD_ComponentObjectUID debido a que los mismos nunca cambian. Más allá de estar creando un micro componente o un componente tradicional, si los AD_ComponentObjectUIDs generados utilizan el nuevo formato universal (PREFIJO-TableName-TimeStamp-Desambiguador, por ejemplo CORE-AD_Column-20191219101230703-090793), entonces no se requiere el mapeo de UIDs al utilizar la funcionalidad CopyToChangeLog.| | |
| |
| Es posible "clonar" el changelog de una base de datos origen a una destino durante el proceso de instalación de un componente, facilitando así el desarrollo distribuido. Para ésto, se crea un componente temporal de desarrollo, el cual luego es instalado en la base de datos general, impactando no solo los cambios que dicho componente tenga registrado, sino también generando el changelog correspondiente en esta última. El resultado final es una base de datos general cuyo contenido y changelog fue virtualmente creado directamente sobre ésta. | Es posible "clonar" el changelog de una base de datos origen a una destino durante el proceso de instalación de un componente, facilitando así el desarrollo distribuido. Para ésto, se crea un componente temporal de desarrollo, el cual luego es instalado en la base de datos general, impactando no solo los cambios que dicho componente tenga registrado, sino también generando el changelog correspondiente en esta última. El resultado final es una base de datos general cuyo contenido y changelog fue virtualmente creado directamente sobre ésta. |
| |
| ==== Mapeo de UIDs ==== | ==== Mapeo de UIDs ==== |
| | |
| | ^ MUY IMPORTANTE: A partir de la revisión r2819 (Soporte para microcomponents), la lógica de generación de los identificadores universales de registros (campo AD_ComponentObjectUID) se modificó a fin de garantizar un UID único e inequívoco. El nuevo formato universal es: PREFIJO-TableName-TimeStamp-Desambiguador, por ejemplo: CORE-AD_Column-20191219101230703-090793). Es por esto que al utilizar la funcionalidad de CopyToChangelog, no se requerirá mapeo de UIDs ante cualquier desarrollo llevado a cabo a partir de dicha revisión (tradicional o microcomponente). Por defecto el mapeo de UIDs queda desactivado, debiendo forzarlo mediante la propiedad MAPUIDS = Y en el manifest.properties del archivo .jar a instalar. Para más detalles ver [[plugins:microcomponents|Soporte para desarrollo de microcomponentes]] | |
| |
| Un aspecto de especial interés es el de los AD_ComponentObjectUIDs. Dado que en este último caso estamos llevando a CORE un componente desarrollado en otra base de datos, el mapeo no se resuelve sencillamente cambiando FOO por CORE en el UID. Es probable que dicho UID ya exista en la base destino. Se detallan a continuación las acciones que realiza el mapeador durante la "instalación" del componente. | Un aspecto de especial interés es el de los AD_ComponentObjectUIDs. Dado que en este último caso estamos llevando a CORE un componente desarrollado en otra base de datos, el mapeo no se resuelve sencillamente cambiando FOO por CORE en el UID. Es probable que dicho UID ya exista en la base destino. Se detallan a continuación las acciones que realiza el mapeador durante la "instalación" del componente. |
