Blog

Eventos de tabla (Triggers)

Eventos de tabla (Triggers) 1Hemos implementado en V7 los Triggers o Eventos de tabla. Hemos hecho un lavado de cara a nuestros amigos ejecutables y aprovechamos para ordenarlos por tipo y evento, es decir, quedarán de la siguiente manera:

  • Anterior a un alta de ficha
  • Interno a un alta de ficha
  • Posterior a un alta de ficha
  • Anterior a una modificación de ficha
  • Interno a una modificación de ficha
  • Posterior a una modificación de ficha
  • Anterior a una baja de ficha
  • Interno a una baja de ficha
  • Posterior a una baja de ficha

Tendremos que ir creándolos a medida que los necesitemos, tratándose como subobjetos del objeto tabla, al igual que actualizaciones, índices, componentes de índices, etc., pero tendrán un número limitado, claro está, uno de cada tipo, por lo que no se repetirán.

Por otro lado, esto nos lleva a tener que contemplar una cierta problemática: los objetos visuales no viajan con la caja de datos, ni éstas últimas heredan cajas de objetos visuales. Sin embargo, los triggers pueden hacer uso de objetos visuales puesto que al fin y al cabo tienen disponibles las mismas instrucciones que los procesos. Una práctica habitual es que el trigger no contenga nada más que una llamada a un proceso y que sea en éste donde programemos todo, para poder reutilizarlo en otros eventos.

Veremos cómo resolver esto, puesto que es una problemática que se repite, por ejemplo en tablas estáticas donde se necesitan iconos, en punteros indirectos, donde se definen formularios para altas, etc.

Como posibles soluciones: en el caso del puntero indirecto, por ejemplo, lo que podríamos hacer sería que la selección del formulario que se muestre en el caso de un alta se haría en el formulario donde se llama al puntero indirecto (tal y como lo permite un botón de alta asociado a un control de edición) y no en el propio campo que es donde se hace ahora.

Lo que haremos también es permitir que ciertos objetos, como el objeto Proceso, puedan guardarse en una caja de datos. De esta manera podemos seguir usando estos objetos pero sin depender de la caja de objetos visuales y, por tanto, de la interacción del usuario. Convendréis con nosotros en que un proceso de la caja de datos no puede esperar por una acción del usuario final.

Esto es sobre todo porque nuestra intención es que las cajas de datos sean autónomas, autosuficientes, independientes del usuario final, para que sean más seguras aún si cabe, y garantizar su aislamiento, para que no se vea en ningún caso comprometida la integridad de los datos y proteger vServer.

Por último, y no por ello menos importante, al contrario, a resultas de este tratamiento, de que la caja sea autónoma y aislada, y del funcionamiento de la herencia, podemos estar seguros de que cuando varias cajas heredan cierta caja, todas trabajarán con esa misma caja de igual forma, ya que tendrá no sólo todos los triggers, si no que tendrá todos los maestros y tablas enlazadas (tablas estáticas, hermanos contiguos, etc.), campos, índices, actualizaciones e históricos, por lo que también estamos garantizando la integridad en el ámbito de la herencia.

Por tanto podremos olvidarnos de controlar que estemos modificando el proyecto correcto, de copiar las tablas modificadas en los proyectos que las comparten, de añadir en cada proyecto todos los maestros y tablas enlazadas y eliminar los enlaces históricos que no existen en los proyectos de destino, etc.

7 thoughts on “Eventos de tabla (Triggers)

  1. El tema de los Triggers es una opción, de las que más me gustaron la principio y que luego no puedo usar siempre que quiero.

    Estaría bien que todas las opciones se pudiesen controlar mejor el punto en el que se ejecuta y que se ejecute igual independientemente de que esa alta, baja o modificación.

    Sobretodo el proceso posterior a un… es un proceso que si realmente fuera el ultimo en ejecutarse después de guardar la ficha tendría mas potencia.

    Un montón de veces procesos adecuados para ir en este punto los he tenido que poner en el botón de aceptar en la opción de proceso posterior.

    El tema de poder asociar a un evento de tabla un proceso, es una opción muy potente que nos permitiría controlar un montón de cosas independientemente de los objetos.

    Para poder potenciar esto mucho más y no depender en ciertos procesos automáticos, que no dependan del usuario final como comentáis, de la parte grafica pondría los procesos de la forma siguiente:

    Anterior a… que realmente sea el primer proceso en ejecutarse, de esta forma independiente mente de objetos podríamos dar permisos de ejecución.

    Interno a… añadir una función o una variable que nos permita controlar el campo que se esta modificando, esta función con la de campo vació nos permitiría realizar los controles de ciertos campos en el evento.

    Posterior a… si realmente es el ultimo en ejecutarse todas las altas en otras tablas después de guardar esa ficha se realizarían correctamente. En estos momentos el proceso Posterior a y el Interno a no se diferencian mucho.

    La filosofía seria potenciar los Triggers para depender menos de la parte grafica.

    No recuerdo quien decía referente a las versiones actuales que todo lo que puedas programar en la parte Izquier

  2. El tema de los Triggers es una opción, de las que más me gustaron la principio y que luego no puedo usar siempre que quiero.

    Estaría bien que todas las opciones se pudiesen controlar mejor el punto en el que se ejecuta y que se ejecute igual independientemente de que esa alta, baja o modificación.

    Sobretodo el proceso posterior a un… es un proceso que si realmente fuera el ultimo en ejecutarse después de guardar la ficha tendría mas potencia.

    Un montón de veces procesos adecuados para ir en este punto los he tenido que poner en el botón de aceptar en la opción de proceso posterior.

    El tema de poder asociar a un evento de tabla un proceso, es una opción muy potente que nos permitiría controlar un montón de cosas independientemente de los objetos.

    Para poder potenciar esto mucho más y no depender en ciertos procesos automáticos, que no dependan del usuario final como comentáis, de la parte grafica pondría los procesos de la forma siguiente:

    Anterior a… que realmente sea el primer proceso en ejecutarse, de esta forma independiente mente de objetos podríamos dar permisos de ejecución.

    Interno a… añadir una función o una variable que nos permita controlar el campo que se esta modificando, esta función con la de campo vació nos permitiría realizar los controles de ciertos campos en el evento.

    Posterior a… si realmente es el ultimo en ejecutarse todas las altas en otras tablas después de guardar esa ficha se realizarían correctamente. En estos momentos el proceso Posterior a y el Interno a no se diferencian mucho.

    La filosofía seria potenciar los Triggers para depender menos de la parte grafica.

    No recuerdo quien decía referente a las versiones actuales que todo lo que puedas programar en la parte Izquier

  3. Posiblemente lo que voy a decir sea una tonteria… pero por si acaso no lo es:

    Si se permite guardar procesos en las cajas de datos y estos procesos llaman, p. ej, a búsquedas, cestas, etc. ¿También habría que guardarlas en la caja de datos para que todo funcionase? ¿Podríamos hacerlo o serían procesos limitados?

    ¿Sería «mejor» dar la posibilidad de utilizar objetos de las cajas de objetos que hereden a la de datos a través de la «conexión» establecida con esta herencia?… Es decir, aunque no podamos directamente marcar como heredadas las cajas de objetos desde las de datos, utilizar objetos a través de las relaciones de herencia establecidas a la inversa. (Algo parecido a la definición automática de los enlaces plurales que realiza v7).

    De esta forma, se mantendría el criterio de que las cajas de datos sólo almacenan estructuras y datos y las de objetos sólo objetos visuales.

    No se si esto que digo es viable, factible, posible, si lo lía todo demasiado o que… pero se me ha ocurrido y lo suelto por si sirve para algo.

    Un saludo,

    Fran.

  4. Gracias por todos vuestros comentarios, nos estáis ayudando, y mucho, a poder explicaros mejor todas las nuevas tecnologías de Velneo V7.

    Nuestra intención con los triggers es que su ámbito se reduzca al sitio en que se usan y ejecutan, a la caja de datos.

    Si necesitas que varios triggers hagan lo mismo, no necesitas más que llamar a un proceso, el mismo desde cada uno de los eventos. Eso ya puedes hacerlo ahora con V6.

    Sin embargo, el enfoque que das implica interacción con el usuario, hablas de dar permisos, comprobar posibilidades, todo ello dependiendo de qué está haciendo el usuario. No es que queramos desprendernos sólo de la parte gráfica, es que queremos que sea autónoma de la caja de objetos visuales, no conoce ni formularios ni procesos que estén en esa caja.

    Además, debemos tener en cuenta que los triggers están asociados a la tabla, a los registros, pegados a la tabla.

    Piensa que funciona como un alta directa en un proceso: tienes un proceso previo, el pre, y proceso posterior, el post (nos faltaría el interno en esta analogía, que estaría en el medio, después de la modificación pero antes de liberar la ficha), y el formulario estaría antes del pre y después, pero no puede interactuar con el registro mientras tanto.

    En cuanto a la posibilidad de relaciones de herencia inversa, debéis tener en cuenta que el criterio no es que las cajas de datos sólo almacenen estructuras y datos y las de objetos sólo objetos visuales, si no que las cajas de datos no heredan objetos visuales. Si heredaran, usarían, y por tanto les afectaría la intervención del usuario.

  5. Cuando me refiero a dar permisos seria dependiendo de los estilos nunca dependiendo del entorno grafico, y era un ejemplo para decir que es lo primero que se ejecute, podría ser una inicialización de variables o información parecida necesaria.

    La idea que quiero explicar es sobretodo que el anterior a… sea lo primero que se realice Antes incluso que el alta y el posterior a… también sea lo ultimo después de haber guardado la ficha exactamente igual que el alta directa que pones de ejemplo y no que al final en vez de poner los procesos en el procesos posterior tengamos que ponerlos en el botón de guardar la ficha.

    Un Saludo, animos y gracias por escucharnos.

  6. Se me olvidaba, el problema por el que guardamos los códigos en un proceso para luego llamarlos desde los Triggers es por no copiar y pegar todas las líneas de una en una, o por si tenemos que ejecutar el código en modo servidor, creo que es más fácil resolver esto que permitir añadir procesos en las cajas de datos. Si estos problemas están resueltos no seria necesario añadir procesos en la caja de objetos.

Dejar un comentario