[Javier Ader]

Buenas. Estoy probando la funcionalidad de Componentes; en forma resumida lo que hice fue crear un Componente y una Versión de Componente; pasarala a estado de desarrollo, crear una tabla en Postgress (la vieja M_Juguetes, solo que con los dos campos de relacionados con componentes , ad_componentobjectuid y ad_componentversion_id agregados; esto creo que no era necesario, pero bueno); creé una tabla a nivel de Liberyta e importé la tabla Postgress; hice una ventana Juguetes; hice una pestaña asociada a la tabla e importe los campos (asocié la tabla a la ventana despues de esto), agregue la entrada al Menú para la ventana y para una carpeta contenedor (Administración Juguetes); cambie a Administrador del Sistema, le agregue los permisos a la ventana y finalmente agregué las entradas al menú para el pefil; me reloguie y creé, modifiqué y eliminé unos juguetes.
Bueno, creo que hasta ahí voy bien. Ahora detuve el desarrollo de la versión y la exporte; aca esta el resultado http://www.eltita.com.ar/libertya/jug01/files/ (el jar http://www.eltita.com.ar/libertya/jug01/files/jug01.jar si lo quieren probar).
Bueno para testearlo cree otra base de datos basandome en ImportarBD_PG.bat que me dejo la instalación inicial (el pljava_install.sql lo saque descomprimiendo el .exe); instale la base de datos (libertya103v3) y los esquemas sqlj y libertya (tambien instale el sqlj.jar en el servidor). Supongo que esto también está bien (salvo que la instalación haga otras modificación a nivel de base de datos que se me paso después de importar estos esquemas; pero creo que no).
Ok (no termino más jajaj) me logueo usando la nueva base de datos y voy a Importar Plugin, y acá finalmente me tiro el error en la instalación del plugin, pero solo cuando intento hacer le postinstall. Acá esta el log que muestra el texto del formularió http://www.eltita.com.ar/libertya/jug01/log-inst-jug01.log y acá los logs de errores en Herramientas -> Preferencias http://www.eltita.com.ar/libertya/jug01/traceInfo-importacion-jug01.log .
En este último se ve que llega a la post instalación y junto con la traza parece que el proceso defualt casi se alcanza a ejecutar (o tal vez alcanzo a hacerlo?), pero la linea que lo ejecuta en VPluginInstallerUtils.doPostInstall parece haber retornado null (worker == null) y por eso dispara una excepción (en el dialogo de error aparecía ” Instalacion cancelada en post configuracion! ” ).
Después veo si debuggueando la aplicación llego al error, pero tal vez venga por otro lado el problema (capaz me falto hacer algo en el desarrollo del componente).
La versión que use es la 10.03 localización AR, instalador automático (la segunda base la hice a “mano”).

PD : los rollback de las transacciones en postgress también revierten los create table? porque yo asumía que aún en estos casos las tablas quedaban (MS Sql Server por ej, creo tiene esta limitación con comandos a nivel de DDL), pero el M_Juguetes no me apareció. Si es así, mucho mejor, si no la reinstalación de un componente bajo una falla puede llegar a ser un dolor de cabeza interesante….

PD 2: por qué hay tantos errores severos relacionados con las secuencias?

[Federico Cristina]

Bien, fue necesario probar a instalar tu .jar para determinar el origen del problema. De todas maneras, estas pruebas nos vienen bien para detectar escenarios que deberán ser corregidos en futuros releases. Veamos…

1) Antes que nada, por razones obvias, muevo este thread a desarrolladores.

2) El problema radica en los comentarios en el preinstall.sql. Esto es por la manera en que se están leyendo las sentencias desde el archivo preinstall.sql contenido en el .jar; al presentarse un comentario en el archivo, toda sentencia posterior queda como parte de dicho comentario. Por lo tanto, actualmente el preinstall.sql no debe contener comentarios.

3) El punto 2 desencadena el error: Siguiendo la consola de eclipse, veo que hay una excepción:

Code:

ERROR: relation “m_juguetes” does not exists

Esto se debe a justamente en dicha transacción no se creo a nivel postgres la tabla juguetes, dado el issue del punto anterior. A partir de este momento TODA sentencia SQL para dicha transacción es ignorada debido a que la transacción fue abortada:

Code:

ERROR: current transaction is aborted, commands ignored until end of transaction block

Esto responde a tu pregunta sobre los errores severos en las secuencias. Los mismos no aparecen luego de quitar los comentarios en el preinstall.sql, ya que la transacción no fue abortada.

Luego de verificar infructuosamente las secuencias, el framework busca el proceso por defecto para realizar la postinstalación, utilizando obviamente la misma transacción que se encuentra abortada, y es por ésto que el SELECT correspondiente devuelve NULL, llevandonos ahora sí al mensaje de error que se presenta en pantalla.

Quitados los comentarios en el preinstall.sql pude realizar la instalación perfectamente.

4) Todo el proceso de instalación de un plugin preinstall.sql, install.xml, postinstall.xml, etc. fue desarrollado utilizando una única transacción que se va propagando donde sea necesario. Por ende postgre te garantiza que de haber un error, el rollback de la misma te llevará al estado previo del inicio de la misma, incluyendo modificaciones en base de datos.

5) Un comentario final: Desde el perfil Administrador del Sistema, deberás agregar el permiso que relaciona la nueva ventana con el perfil correspondiente de manera manual, usando la ventana de Perfil (ad_window_access), dado que por el momento las tablas ad_XXX_access no se encuentran dentro del set de tablas a bitacorear.

Saludos!
Federico

[Javier Ader]

Buenísimo, ahí anduvo… me iba a volver loco. Me habia puesto de debugear con eclipse y como la consola la tengo configurada con un buffer pequeño no había alcanzado a ver el error en la creación del juguete y menos a darme cuenta que la transacción se abortaba y por eso todo lo demás iba a fallar (supongo que el despues de hacer el doPreinstall habria que chequear que la transaccion esta abierta o que este metodo lo haga, si no se sabe en que parte falla). Me daba la sensación que el problema estaba en obtener las nuevas ids desde las secuencias.
Lo de los permisos de acceso ya me había dado cuenta ya que los cambios en AD_Window_Access no se loguean mientras se está en “modo desarrollo” (iba pispiando la tabla AD_Changelog para ver que se insertaba y que no); lo cual veo correcto (los usuarios cambian de instalación en instalación).

Ahora lo que vi es que aunque puso en AD_Changelog las modificaciones que hice a los juguetes (2 creaciones y un delete), estas no fueron a parar ni al install.xml ni al postinstall.xml (y por lo tanto luego de la instalación no tengo juguetes). Esto debe venir porque no “registre” la tabla M_Juguetes dentro de los esquemas de tablas mientras estaba en modo desarrollo (los exportadores alcance a ver que filtran por los esquemas data y metadata); supongo que si lo hubiese hecho despues de detener el desarrollo también habría exportado las modificaciones a las filas a M_Juguetes (aunque no a los esquemas de tablas en si mismos), e.d hubiese exportado los juguetes en particular pero no los cambios a los esquemas. Despues lo investigo un poco más porque igual el tema de los esquemas de tabla no lo termino de comprender del todo.

Unas últimas notas, para no crear un nuevo thread:

– no termino de entender para que sirve el AD_Plugin; al parecer en el proceso de instalación se crea un solo plugin por componente a lo sumo (el plugin queda asociado a la versión del componente siendo instalada, pero solo a una).

– el proceso de desarrollo ralentaba muchísimo las modificaciones de metadatos; supongo que era por las multiples modificaciones en AD_Changelog (por ej, cuando se importan masivamente las columas de una tabla). Ok, mi maquina esta bastante vieja, pero igual creo que la diferencia era bastante notable.

– por qué usaron la tabla AD_Changelog? Estaba desde antes y supongo que estaba pensada para mantener otra tipo de funcionalidad. También tiene una estructura redundante (se nota cuando se hace un insert; no tanto con una modificación simple o elimianción ya que ahi va una sola fila por operación ), e.d no esta normalizada (pienso que debe ser 2 tablas en vez de una, con una relación 1 a muchos; la segunda manteniendo los cambios a nivel de columna de una tabla). Otra limitación que le veo es que el oldvalue y el newvalue parecen tener longitud máxima de 2000 caracteres ; supongo que de ahí viene la limitación para registrar los cambios de datos binarios (a nivel de código vi algunas cosas que intentaban implementar pasando previamente a base64 los datos binarios; pero casi cualquier dato binario va a superar 2000 caracteres, más en base64).

– las notas anteriores no tienen mucha importancia ya que las mejoras andan y seguramente van a traer muchas otras de la mano. Los felicito nuevamente.

[Federico Cristina]

javAd,

Muchas gracias por tomarte el tiempo de ver el nuevo framework y tus consideraciones.

Sobre la bitácora de la tabla M_Juguetes, precisamente se debe a que no está dentro de la nómina de tablas a bitacorear, y por esto que no se guarda en el changelog.

En AD_Plugin quedan registrados los plugins instalados. Esto está pensado para alguna ampliación posterior en la que quizás sea posible activar o desactivar un componente (recordá que la información de AD_Component y AD_ComponentVersion es más para desarrolladores).

Tal como decis, los tiempos para generar la bitácora son considerables (al menos por ahora). Esto se debe – entre otras cosas – a que actualmente todo lo que se bitacorea pasa por PO. Toda sentencia SQL de inserción (obviamente para los casos de interés) fueron convertidas a instanciaciones de objetos, a fin de que sea posible gestionar la bitácora. De todas maneras creo que esta demora es infinitamente menor (y menos propensa a errores) con respecto a llevar un log manual de modificaciones al diccionario de datos a fin de replicar dichas modificaciones en otra instancia de Libertya.

El framework ya utilizaba la tabla AD_Changelog para temas de auditoría, así que simplemente se amplió la lógica para “auditar” más cosas y con un formato más acorde a nuestras necesidades.

Gracias por las felicitaciones!

Saludos,
Federico

[Autor]

Entradas