Autor Tema: Problema inf en GDS 19659 de fecha 22/04/2016 y GDS 40217 Actualizador Mapuche  (Leído 672 veces)

0 Usuarios y 1 Visitante están viendo este tema.

gpiccininno

  • Jr. Member
  • **
  • Mensajes: 53
    • Ver Perfil
    • Email
  • Institución: MPF
  • Nombre y apellido: Graciela Rita Piccininno
  • Teléfono laboral: 4335-4286
  • Utilizo algun sistéma del SIU: Sí
Buenos días.
Seguimos con el inconveniente en la actualización de las tablas del esquema toba_mapuche, que en el caso de utilizarse membresías, da error.
 El instalador/actualizador realiza los siguientes pasos:
 1. Delete/borrado del contenido de todas las tablas en donde el usuario define la estructura de accesos de los usuarios, en el orden de la integridad referencial .
 Se copia a continuación parte del log del motor postgres. Se detecta un primer error: ejecuta cada sentencia DELETE dos veces para algunas tablas, innecesariamente.
..........
 DELETE FROM apex_restriccion_funcional_evt WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_evt WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_ei WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_ei WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_ef WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_ef WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_cols WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional_cols WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);
 DELETE FROM apex_restriccion_funcional WHERE proyecto = 'mapuche' AND restriccion_funcional IN (SELECT res.restriccion_funcional FROM apex_restriccion_funcional AS res WHERE res.proyecto = 'mapuche' AND res.permite_edicion = 1);

 2. Insert en apex_restriccion_funcional de todas las restricciones.
 3. Insert en apex_restriccion_funcional_evt de todos los eventos de todas las restricciones del punto 2.
 4. Insert en apex_restriccion_funcional_ei de todos los ítems de todas las restricciones del punto 2.
 5. Insert en apex_restriccion_funcional_ef de todos los formularios de todas las restricciones del punto 2.
 6. Insert en apex_restriccion_funcional_pantalla de todas las pantallas de todas las restricciones del punto 2.

 La lógica de inserción del instalador/actualizador cambia para las siguientes tablas, en donde por cada registro de apex_usuario_grupo_acc, que representa a un perfil funcional, inserta los ítems relacionados en apex_usuario_grupo_acc_item, los miembros (membresía) en apex_usuario_grupo_acc_miembros, si es que existen y en apex_grupo_acc_restriccion_funcional las restricciones asociadas, si es que existen, todo en ese orden.
 En nuestro caso, tenemos por ejemplo, perfiles funcionales que tienen solo miembros, y éstos a su vez son también perfiles, (tienen que existir en apex_usuario_grupo_acc) y poseen sus respectivos ítems; perfiles funcionales que solo son restricciones, y también pueden darse distintas combinaciones.
 Cuando se actualiza este tipo de árbol, el instalador/actualizador, al proceder a insertar todos los miembros, se encuentra con que éstos todavía no fueron insertados como perfiles funcionales, y da ERROR. Para ello ordena los registros de la tabla apex_usuario_grupo_acc por la columna “usuario_grupo_acc”.Pero de existir miembros, todos ellos son a su vez perfiles funcionales, por lo que lo más lógico sería primero insertar todos los perfiles funcionales, sus ítems si los tiene y sus restricciones si las tiene, y luego, en último lugar, los miembros. Esta es la secuencia de inserción que tienen las tablas según el comportamiento de la aplicación y esa misma secuencia debería respetar el instalador/actualizador. (Es decir, no se puede agregar un miembro a un perfil, si éste todavía no fue dado de alta como perfil). Adoptar un criterio que revierte la integridad referencial, es lo que da orígen a errores.
 Nos vemos obligados a establecer y controlar un orden forzado, por fuera, que no sería necesario, dado que esto le agrega a la definición de perfiles desde la aplicación una complejidad extra, porque hay que estar recordando en el momento de efectuar las altas, qué prefijo colocar, dependiendo de qué se trata, dado que desde la aplicación esa columna no se puede consultar ni se muestra en ninguna pantalla. Además esto le quita flexibilidad, porque de tener que incorporar otro tipo de combinatoria, posiblemente habría que redefinir el orden. Adjuntamos un ejemplo donde forzamos el orden, pero consideramos que no es la solución, dado que estamos trabajando constantemente con los perfiles, y esto implica tener que llevar un control por fuera de la aplicación.
Como le mencionamos a Emiliano Jaureguiber,  "no estamos solicitando una mejora, sino la corrección de un error".Obviamente no conocemos el código específicamente, pero esta corrección implicaría algo sencillo. Sería insertar todos los registros en apex_usuario_grupo_acc de una sola vez. No se si queda claro que no se trata de un orden, es lógica. Integridad referencial básica."  El nos sugirió ingresar el tema por el foro.
Aguardamos sus comentarios.
Gracias.
Atte.
Graciela Piccininno

richard

  • Moderador Global
  • *****
  • Mensajes: 2998
    • Ver Perfil
  • Institución: SIU
  • Nombre y apellido: Ricardo Dalinger
  • Sistema: SIU-Toba
Hola Graciela,
1. Delete/borrado del contenido de todas las tablas en donde el usuario define la estructura de accesos de los usuarios, en el orden de la integridad referencial .
 Se copia a continuación parte del log del motor postgres. Se detecta un primer error: ejecuta cada sentencia DELETE dos veces para algunas tablas, innecesariamente.
Es verdad.. se trata de un bug que aparentemente esta desde 2010, gracias por observarlo.

Cita
La lógica de inserción del instalador/actualizador cambia para las siguientes tablas, en donde por cada registro de apex_usuario_grupo_acc, que representa a un perfil funcional, inserta los ítems relacionados en apex_usuario_grupo_acc_item, los miembros (membresía) en apex_usuario_grupo_acc_miembros, si es que existen y en apex_grupo_acc_restriccion_funcional las restricciones asociadas, si es que existen, todo en ese orden.

No hay ningún cambio en la lógica, se intenta insertar los registros preservando la integridad referencial en lo posible, que los triggers no estén desactivados permite ademas que se vayan reportando los errores con la mayor granularidad posible.

Cita
Para ello ordena los registros de la tabla apex_usuario_grupo_acc por la columna “usuario_grupo_acc”.Pero de existir miembros, todos ellos son a su vez perfiles funcionales, por lo que lo más lógico sería primero insertar todos los perfiles funcionales, sus ítems si los tiene y sus restricciones si las tiene, y luego, en último lugar, los miembros. Esta es la secuencia de inserción que tienen las tablas según el comportamiento de la aplicación y esa misma secuencia debería respetar el instalador/actualizador. (Es decir, no se puede agregar un miembro a un perfil, si éste todavía no fue dado de alta como perfil). Adoptar un criterio que revierte la integridad referencial, es lo que da orígen a errores.

No estas teniendo en cuenta un pequeño detalle, en la aplicación la secuencia de creación/actualización la generas vos via el criterio humano, no creas los perfiles en el orden incorrecto porque existe una de dos posibilidades:

- El perfil  ya existe, en cuyo caso no hay problema asignas la membresia y listo
- El perfil  no existe, en cuyo caso cancelas la asignación y vas a darlo de alta, para luego volver y asignarlo.

Es decir, toda la operatoria se realiza desde el punto de vista del perfil miembro.. no desde el padre.
Durante la regeneración el procesamiento de los archivos es secuencial,  no hay lógica para determinar si el perfil es miembro o no de otro y al ser contenido estático no se puede distinguir que fila se debe "retrasar" en la ejecución.
Ante ese problema (que se puede dar en cualquier tabla relacionada en realidad) la regeneración tiene dos opciones:

- Reportar el error inmediatamente y seguir adelante hasta completarse (dejándote para arreglar el problema). Comportamiento habitual
- Esperar hasta el final de la transacción, abortar y dejarte con la responsabilidad de arreglar el problema y volver a repetir todo el proceso (cuantas veces sea necesario). Situación que se transito en su momento.

Ahora, como la solución del problema (durante una actualización en producción) puede ser tan simple como ir y editar una linea (quitar un item/rf), es que se decidió dejar los perfiles autocontenidos en archivos individuales, de forma de tener que tocar lo menos posible.. y saber que todo lo que esta allí esta relacionado (en un volumen de datos manejable), la alternativa planteada implica un archivo con todos los perfiles, otro con todas los items de perfiles, otro con la relación de membresias, etc.. con lo cual ante un problema, necesitas tener abiertos múltiples archivos de un tamaño mayor y hacer la conexión lógica entre los datos manualmente.

Cita
Nos vemos obligados a establecer y controlar un orden forzado, por fuera, que no sería necesario, dado que esto le agrega a la definición de perfiles desde la aplicación una complejidad extra, porque hay que estar recordando en el momento de efectuar las altas, qué prefijo colocar, dependiendo de qué se trata, dado que desde la aplicación esa columna no se puede consultar ni se muestra en ninguna pantalla.

El orden al que haces mención emana de la forma en que se procesan los archivos xml al momento de regenerar, como se trata de un orden alfabético se les sugirió que incorporen dicho criterio en la creación de los ids. Si es cierto que el cuadro que lista los perfiles podría tener la columna ID como parte del mismo, de manera de poder visualizar de manera mas sencilla lo que se tiene.

Cita
Además esto le quita flexibilidad, porque de tener que incorporar otro tipo de combinatoria, posiblemente habría que redefinir el orden. Adjuntamos un ejemplo donde forzamos el orden, pero consideramos que no es la solución, dado que estamos trabajando constantemente con los perfiles, y esto implica tener que llevar un control por fuera de la aplicación.

Aquí el único requerimiento es de orden alfabético... nadie dice que los identificadores no puedan tener X o Y forma, si que la estructura este ordenada.
Si incorporas otra combinatoria con una estructura aparte, no tiene porque influirte en lo que ya tenes y si tiene lazos, necesariamente vas a tener que reordenar porque cambiaste la convención para nombrar las cosas.

Dicho esto, con un par de sentencias SQL por perfil rearmas toda la estructura.

Cita
Como le mencionamos a Emiliano Jaureguiber,  "no estamos solicitando una mejora, sino la corrección de un error".

Lo que para ustedes es un error... para mi es una decisión de diseño que se tomo en su momento por factores X, me gusta?..no del todo, de haber estado hubiera hecho otra cosa.. pero entiendo que dentro de lo que se planteo es una solución de compromiso. Cambiar eso hoy impacta todos los sistemas del SIU y los propios de las instituciones, sin contar instalaciones.

Pasar de editar un perfil autocontenido a editar múltiples archivos y tener que tocarlos todos en el peor de los casos, no es lindo.. te tomo que solo seria ante un problema.. pero en medio de una actualización es cuando mas se queja la gente y mas urgencia les agarra. No es lo mismo sacarle 4 hojas a una rama ... que tener que decidir que 4 hojas hay que sacar de entre todo el árbol.

Cita
Obviamente no conocemos el código específicamente, pero esta corrección implicaría algo sencillo. Sería insertar todos los registros en apex_usuario_grupo_acc de una sola vez. No se si queda claro que no se trata de un orden, es lógica. Integridad referencial básica."  El nos sugirió ingresar el tema por el foro.

Luego de 10 años de uso nada es sencillo creeme, aun así.. para poder llevar adelante eso, hay que modificar la exportación de esos datos en primer lugar para cambiar como se separan en xml y quedaríamos en lo que te planteaba antes. Esto solo saldría en una nueva versión de segundo dígito, con lo cual tampoco te llegaría instantáneamente.

Lo ideal seria tirar todo al diablo.. las membresias hoy no son estrictamente necesarias ya (cada usr puede tener múltiples PF asociados) pero incluso se podría separar mejor y la división entre desarrollo/producción (precursora de todos los males), tendría que recibir la muerte que nunca tuvo pero siempre mereció (deshonrosa por supuesto), los perfiles deberían ser de la instalación y no del proyecto.

No es que no se hayan considerado alternativas, solo que muchas serian volver al lugar del cual se pidió salir en su momento.
Otras implican cambios que tienen mas impacto en los usuarios que los males que resuelven.
Y la que le pondría solución final a este y otros problemas.. me granjearia el apodo  K-19.

Saludos
Richard

« Última Modificación: Mayo 31, 2019, 05:26:13 pm por richard »
Twitter es al incontinente verbal,  lo que los dulces al diabetico.