Llame a un procedimiento almacenado desde un gatillo

Question

He creado un procedimiento almacenado en MySQL usando la siguiente sintaxis.

DROP PROCEDURE IF EXISTS `sp-set_comment_count`;

DELIMITER $$

CREATE PROCEDURE `sp_set-comment_count` (IN _id INT)
BEGIN
   -- AC   - AllCount
   DECLARE AC INT DEFAULT 0;

   SELECT COUNT(*) AS ac
     INTO AC
     FROM usergroups AS ug
LEFT JOIN usergroup_comments AS ugm ON ugm.`gid` = ug.`id`
LEFT JOIN mediagallery AS dm ON ugm.mid = dm.`id`
    WHERE dm.`status` NOT IN (200, 201, 202, 203, 204, 205)
      AND ug.`id` = _id;

   UPDATE usergroups
      SET allCount = AC,
    WHERE usergroups.`id` = _id;

END $$
DELIMITER ;

Para su información, he simplificado enormemente el procedimiento almacenado, pero sé que funciona sin ningún problema.

Lo que me gustaría poder hacer es configurar un desencadenante de UserGroup_Comments que funcione así.

DROP TRIGGER IF EXISTS `usergroups_comments_insert` 

CREATE TRIGGER `usergroups_comments_insert` AFTER INSERT ON `usergroups_comment`
    FOR EACH ROW
    BEGIN
       CALL sp-set-comment_count(NEW.`gid`);
    END;

Pero por alguna razón, cada vez que hago MySQL me arroja un error que es menos útil afirmar que hay un error de sintaxis en la línea 4.

He peinado a través de la documentación MySQL y encontré información sobre restricciones de los desencadenantes, pero encontré que era bastante complicado.

http://dev.mysql.com/doc/refman/5.1/en/stored-program-restrictions.html

Cualquier idea sería útil.

Answer 1

Entonces resulta que este es el problema que me atormentó durante unas horas lo cree o no.

Puedo definir fácilmente un procedimiento llamado Sp_Set-Comment_Count. Sin embargo, al llamar a dicho procedimiento, no funciona de la misma manera.

Llame a sp_set -comment_count (solo puedo suponer que esto se debe a que el servidor interpreta el - como un menos).

Desde entonces he cambiado el nombre del procedimiento almacenado para usar solo subrayos y parece haber resuelto todo.

Answer 2

Hay una gran razón por la cual nunca debe llamar a los procedimientos almacenados desde los desencadenantes.

Los desencadenantes son, por naturaleza, procedimientos almacenados. Sus acciones son prácticamente difíciles de retroceder. Incluso si todas las tablas subyacentes son innodb, experimentará un volumen proporcional de bloqueos de hileras compartidas y una intermitencia molesta de bloqueos de fila exclusivos. Tal sería el caso si los desencadenantes manipularan tablas con Insertos y actualizaciones que se estancan para realizar una alta resistencia MVCC Dentro de cada llamada a un gatillo.

No olvides que los desencadenantes requieren gastos generales. De hecho, según Programación de procedimientos almacenados de MySQL, página 256 debajo de la cabeza "disparador de arriba" dice lo siguiente:

Es importante recordar que, por necesidad, los desencadenantes agregan sobrecarga a la declaración DML a la que se aplican. La cantidad real de sobrecarga dependerá de la naturaleza del desencadenante, pero, como todos los desencadenantes de MySQL se ejecutan para cada fila, la sobrecarga puede acumularse rápidamente para declaraciones que procesan grandes cantidades de filas. Por lo tanto, debe evitar colocar las declaraciones SQL costosas o el código de procedimiento en desencadenantes.

Una explicación ampliada de la sobrecarga de activadores se da en las páginas 529-531. El punto final de esa sección establece lo siguiente:

La lección aquí es esta: dado que el código de activación se ejecutará una vez por cada fila afectada por una declaración DML, el desencadenante puede convertirse fácilmente en el factor más significativo en el rendimiento de DML. El código dentro del cuerpo del activador debe ser lo más ligero posible y, en particular, cualquier declaración SQL en el disparador debe ser compatible con índices siempre que sea posible.

Le expliqué otros aspectos desagradables de los desencadenantes en una publicación anterior.

RESUMEN

me gustaría Recomiendo encarecidamente no llamar a ningún procedimiento almacenado desde un gatillo, incluso si MySQL lo permite. Debería verificar las restricciones actuales para MySQL 5.5.

Answer 3

Si dice sobre el error de sintaxis, lo más probable es que olvidó cambiar delimitador (como lo hizo para el procedimiento almacenado). Así que tú necesitas

DELIMITER $$
CREATE TRIGGER `usergroups_comments_insert` AFTER INSERT ON `usergroups_comment`
FOR EACH ROW
BEGIN
   CALL sp_set_count(NEW.`gid`);
END;
$$

Answer 4

Parece la coma después AC es un error de sintaxis:

UPDATE usergroups
   SET allCount = AC,
 WHERE ........