[MySQL] EVENT 'event_name' variabel maken in trigger

[LeonM]

Ik heb een tabel 'acties' welke acties bevat welke op een bepaald tijdstip moeten worden uitgevoerd. Hiervoor wil ik het MySQL event mechanisme gebruiken.

Nu wil ik de events van MySQL consistent houden met wat er in mijn acties tabel staat, dmv triggers op de acties tabel.

Het probleem is dat de syntax voor events een event_name vereisen en ik deze maar niet 'dynamisch' krijg. Ik wil dat het event_name gelijk is aan 'action_[id]' waarbij [id] de primary key uit de acties tabel is.

Als er bijvoorbeeld een record uit de acties tabel word verwijderd wil ik zoiets als dit:

SQL:

CREATE TRIGGER delete_action BEFORE DELETE ON actions
FOR EACH ROW
DROP EVENT IF EXISTS CONTACT_WS('_', 'action', OLD.id);

Dat werkt dus niet, je mag op de plek van het event name blijkbaar geen subquery of function neerzetten.

Ik heb al geprobeerd met variabelen te werken:

SQL:

SET @event_name := 'action_1';
DROP EVENT IF EXISTS @event_name;

Maar dat werkt niet. Toen kwam ik op het idee prepared statements te gebruiken:

SQL:

PREPARE stmt1 FROM 'DROP EVENT IF EXISTS ?';
SET @event_name := 'action_1';
EXECUTE stmt1 USING @event_name;

Maar dat gaat al mis bij de prepare stap.


Iemand nog een idee / hack waarmee ik dit wel voor elkaar krijg? Voor de duidelijkheid, de query word dmv een trgger uitgevoerd, dus ik probeer niet vanuit PHP ofzo een dynamische query bouwen.

[ Voor 0% gewijzigd door LeonM op 31-07-2012 17:20 . Reden: typo ]

[pedorus]

Lijkt me logischer om alles vanuit een stored procedure te doen. Daarnaast vraag ik me af of het zinvol is om 1 event per rij te hebben, of dat je dit beter kan groeperen.

Ik zie geen mogelijkheid om dit te doen zonder dynamische sql, en dat kan niet in een trigger

[LeonM]

pedorus schreef op dinsdag 31 juli 2012 @ 22:21:
Lijkt me logischer om alles vanuit een stored procedure te doen. Daarnaast vraag ik me af of het zinvol is om 1 event per rij te hebben, of dat je dit beter kan groeperen.

één record uit de acties tabel correspondeerd met exact één actie, dus één event. Het groeperen van de events kan natuurlijk, maar heeft voor mijn toepassing geen nut.
Wat zou volgens jou het verschil/voordeel zijn van een stored procedure t.o.v een trigger?

pedorus schreef op dinsdag 31 juli 2012 @ 22:21:
Ik zie geen mogelijkheid om dit te doen zonder dynamische sql, en dat kan niet in een trigger

Wel op een andere manier?

[pedorus]

Ja, met een stored procedure dus, waarin je zowel een rij aanmaakt, als die event (uit)zet ( Mysql 5.0.13+ staat dynamische sql toe in stored procedures).

[LeonM]

Ik ben wat aan het rondzoeken geweest en ben op de volgende oplossing gekomen:

SQL:

CREATE PROCEDURE delete_action_event(IN id INT)
BEGIN
    SET @q = CONCAT('DROP EVENT IF EXISTS action_', id, ';');
    PREPARE stmt FROM @q;
    EXECUTE stmt;
END

Dit werkt ook niet, ik krijg de volgende error:

code:

#1295 - This command is not supported in the prepared statement protocol yet

Begin wel een beetje moelijk te worden van MySQL, geef mij maar gewoon Postgres...

[LeonM]

Ook in MySQL 5.6 is het zo te zien nog steeds niet mogelijk:
http://dev.mysql.com/doc/...-prepared-statements.html

Zie ook hier:
http://bugs.mysql.com/bug.php?id=42337

En zo te zien zijn er ook weinig ontwikkelaars die zich er druk om maken:
http://forge.mysql.com/worklog/task.php?id=2871


Volgens mij houd het een beetje op zo. Het enige wat ik nu nog aan uitwegen zie is een extern proces die de events en actie tabel synchroon houd... Smerig, maar dat werkt tenminste...

[pedorus]

Kun je de rij niet gewoon uit INFORMATION_SCHEMA.EVENTS verwijderen?

[LeonM]

pedorus schreef op woensdag 01 augustus 2012 @ 13:09:
Kun je de rij niet gewoon uit INFORMATION_SCHEMA.EVENTS verwijderen?

Nope, dat is namelijk een view. Een virtuele view zelfs...

Events zijn virtuele records, een soort van wrapper op de event handler van het OS. De realtime clock in de CPU geeft een interrupt aan het OS op het moment dat het juiste moment is aangebroken, welke op zijn beurt een signal stuurt naar mysqld. Door middel van de EVENT statements word ervoor gezorgd dat de events synchroon worden gehouden met wat er aan het OS is doorgegeven. Daarom spreekt met van CREATE, ALTER en DROP in plaats van INSERT, UPDATE en DELETE

[pedorus]

Het zou ook niet moeten kunnen, maar ik vroeg het me gewoon af of het in werkelijkheid toch kon

Dus tsja, dan maar de applicatie aanpassen waarvandaan je de query doet, of iets anders maken voor de synchronisatie inderdaad.