Triggers

Un trigger es una regla que vive dentro de la base de datos y se dispara sola cada vez que una fila de una tabla se inserta, se cambia o se elimina. No depende de quién escribió: venga la escritura de una pantalla, de una API, de un script o de otra aplicación conectada a la misma base de datos, el trigger corre.

Ese es el argumento a favor de los triggers, y también el cuidado que exigen — lógica que corre sin que nadie la llame es lógica que nadie ve suceder.

#Dónde viven los triggers

En el árbol del datasource, dentro del grupo Programación, junto a las Funciones / Procedimientos:

Hacer clic en un trigger lo abre en una pestaña del espacio de trabajo, con su flujo dibujado.

#Crear un trigger

1. Pasa el ratón por el datasource y abre el menú ⋯.
2. Elige Nuevo trigger. Se abre el diálogo con los datos iniciales del trigger — el flujo se construye después en el canvas.
3. Rellena:

Campo	Qué es
Nombre	El nombre del trigger en la base de datos. La convención sugerida es trg_mi_tabla.
Tabla	La tabla vigilada.
Momento	BEFORE (antes de que la fila se escriba) o AFTER (después).
Eventos	INSERT, UPDATE, DELETE — al menos uno. Algunos motores aceptan varios en el mismo trigger, otros solo uno.

4. Confirma con Crear y abrir canvas.

El trigger nace como borrador: ya existe en la plataforma, pero aún no se ha aplicado a la base de datos. Mientras sea borrador, el árbol lo identifica como tal.

#Momento y eventos, en la práctica

Elección	Para qué
BEFORE INSERT/UPDATE	Normalizar o completar valores antes de que se guarden — poner un código en mayúsculas, rellenar un campo derivado.
AFTER INSERT/UPDATE/DELETE	Reaccionar a lo que ya pasó — escribir un historial, actualizar un total en otra tabla.

Los valores de la fila están disponibles según el evento: los Valores nuevos (NEW) existen en el INSERT y en el UPDATE; los Valores antiguos (OLD) solo aparecen cuando el trigger escucha UPDATE o DELETE — en un INSERT no hay fila antigua que mostrar.

#El canvas del trigger

El flujo se dibuja en un canvas, y la pista de arriba resume el gesto: arrastra funciones/procedimientos del árbol al canvas; doble clic en una caja configura sus outputs/inputs.

En la barra sobre el canvas están, de izquierda a derecha:

Botón	Qué hace
Definiciones	Reabre nombre, tabla, Momento y Eventos del trigger.
(el resumen)	El nombre, la tabla, el momento y los eventos, siempre a la vista.
Expresión	Añade un nodo de expresión al flujo.
Ver SQL	Muestra el trigger compilado, sin ejecutar nada.
Guardar y aplicar en la BD	Guarda y aplica el trigger al motor.

#La caja de la tabla — lo que entra en el flujo

La primera caja del canvas es la tabla: de ella salen los valores de la fila que disparó el trigger. Hazle doble clic para abrir los Outputs del trigger y elegir lo que este trigger expone al flujo: columnas individuales, la fila entera (JSON), o ambos.

• Valores nuevos (NEW) — la fila tal como queda.
• Valores antiguos (OLD) — la fila tal como estaba.
• En cualquiera de los dos, además de las columnas sueltas, puedes exponer la fila entera (JSON) — útil para entregarlo todo de una vez a una función de historial.

Cada salida elegida se convierte en un puerto en la caja, listo para conectar.

#Las funciones y los procedimientos

El trabajo, en un trigger, lo hacen funciones y procedimientos que ya existen en la base de datos. Arrástralos del árbol (Programación ▸ Funciones / Procedimientos) al canvas: cada uno se convierte en una caja con un parámetro por entrada.

1. Conecta un puerto de la tabla al parámetro que alimenta — el parámetro pasa a mostrarse como conectado.
2. Un parámetro sin conexión se queda con su valor por defecto.
3. Las funciones también devuelven valor: el puerto de retorno puede alimentar otra caja, encadenando pasos.
4. El menú de la propia caja tiene Quitar del flujo.

Para deshacer una conexión, haz clic en la línea: ¿Quitar esta conexión? El parámetro deja de recibir este valor.

#Los nodos de expresión

Entre un puerto y un parámetro no siempre el valor sirve tal cual. El botón Expresión añade un nodo que refina/transforma valores: declaras Inputs (con + input), les conectas puertos, y escribes la Expresión SQL usando {a}, {b}… para los inputs conectados — por ejemplo upper({a}) || '-' || {b}. El resultado sale por el puerto del nodo y sigue hacia donde quieras.

Haz doble clic en el nodo para configurarlo (la propia caja dice doble clic para editar… mientras está vacía).

#Ver el SQL antes de aplicar

Ver SQL abre la previsualización — SQL del trigger (previsualización) — con el aviso que importa: Compilado con tus cambios actuales — nada se ha ejecutado. Evalúa y aplica cuando quieras.

Es el paso de seguridad: ves exactamente lo que se va a crear en la base de datos, puedes copiarlo, mostrárselo a quien administra el motor, y solo después aplicar. El mismo diálogo tiene el botón Guardar y aplicar en la BD a mano.

#Aplicar el trigger

Guardar y aplicar en la BD hace las dos cosas: guarda el diseño y crea el trigger en el motor. Cuando va bien, la plataforma confirma: Trigger aplicado en la base de datos.

Antes de aplicar, el diseño se verifica. Los rechazos son explícitos:

Mensaje	Qué falta
Dale un nombre al trigger (Definiciones).	El nombre.
Elige la tabla (Definiciones).	La tabla vigilada.
Elige al menos un evento (Definiciones).	Al menos uno de INSERT/UPDATE/DELETE.
El canvas no tiene ninguna función/procedimiento.	Un flujo vacío no hace nada — arrastra al menos una función.
Hay un nodo de expresión sin expresión definida.	Un nodo de expresión en blanco.

#Eliminar un trigger

El menú ⋯ del trigger en el árbol tiene Eliminar, con confirmación — ¿Eliminar el trigger «…»? — y es definitivo: el trigger sale de la base de datos.

#Ver lo que está en la base de datos

La consola SQL, bajo el diagrama del modelo, es el sitio para confirmar el efecto de un trigger: escribe una consulta, Ejecutar, y mira las filas reales. También por aquí se inspecciona lo que ya estaba antes de que tú llegaras.

#¿Trigger, script o workflow?

Las tres cosas automatizan, y la elección correcta evita meses de confusión:

Herramienta	Corre…	Buena para
Trigger	Dentro de la base de datos, con cada escritura de la tabla.	Reglas que tienen que valer para todas las escrituras: historial, campos derivados, totales.
Script	Fuera de la base de datos, a mano, programado o como paso de una API.	Trabajo pesado, integraciones, archivos, envíos — todo lo que tarda o habla con el exterior.
Workflow	Como un proceso con pasos, decisiones y tareas humanas.	Aprobaciones, circuitos con personas en medio, esperas.

#¿Por qué no…?

• ¿Por qué no aparece Nuevo trigger en el menú del datasource? El motor conectado no soporta triggers diseñados en el canvas. Sigues pudiendo crearlos en SQL, y aparecen en el árbol como triggers externos.
• ¿Por qué el trigger sigue diciendo que es borrador? Fue creado pero aún no se ha aplicado. Ábrelo y usa Guardar y aplicar en la BD.
• ¿Por qué no veo los Valores antiguos (OLD)? El trigger no escucha UPDATE ni DELETE. En un INSERT no existe fila antigua.
• ¿Por qué no puedo conectar un puerto a un parámetro? No todas las conexiones tienen sentido — confirma que estás conectando una salida (a la derecha de la caja) a una entrada (a la izquierda de la otra).
• ¿Por qué el trigger no hace nada? Un flujo sin funciones no genera ningún trabajo: la compilación lo rechaza. Y confirma el Momento — un BEFORE y un AFTER no ven lo mismo.
• ¿Por qué las escrituras se volvieron lentas después de crear el trigger? El trigger corre en cada fila escrita. Si llama a trabajo pesado, ese trabajo pasó a ocurrir en cada inserción — en esos casos, el sitio es un script programado.