ugrás a tartalomhoz

SP hívása triggerből

aspirany · 2008. Júl. 5. (Szo), 18.40
Sziasztok!

A kérdésem az lenne lehet-e triggerből sp-t meghívni?
vagy az alább általam írt példa nem is működő képes.

A hiba a következő:Recursive limit 0(as set by the max_sp_recursion_depth variable)was exceeded for routine

A következő triggert csináltam:

CREATE TRIGGER `partner_before_upd_tr` BEFORE UPDATE ON `partner`
FOR EACH ROW
BEGIN
CALL sp_login_out('AA');
END;

A meghívott sp_login_out a következő
CREATE DEFINER = 'root'@'localhost' PROCEDURE `sp_login_out`(IN nev VARCHAR(20))
NOT DETERMINISTIC
CONTAINS SQL
SQL SECURITY DEFINER
COMMENT ''
BEGIN
INSERT INTO belep_log (NAME) VALUES (nev);
END;

KÖSZÖNÖM a segítséget!
‹ Ütemezett feladat 5.1.x Kis-nagybetűérzékeny LIKE ›
 ■
1

Elvileg lehet

janoszen · 2008. Júl. 5. (Szo), 19.35
Elvileg lehet, de nem próbáltam ki. Inkább a rekurzív hívások limitje játszik itt közre a hibaüzenet alapján. Lásd még: http://dev.mysql.com/doc/refman/5.0/en/routine-restrictions.html

Egyébként miért nem teszed be nyersen az insertet? Én is próbálkoztam MySQLben struktúráltan programozni, view-kkal és SP-kkel, de rá kellett jönnöm, hogy (még) sajnos nem alkalmas rá túlzottan, tehát célszerű a bonyolultságot alacsonyan tartani.
3

szerintem nem :)

virág · 2008. Júl. 6. (V), 06.35
Egyébként miért nem teszed be nyersen az insertet?


Azért nem, mert ugye újrahasznosíthatóság, szépség és nem illik gányolni SQL-ben sem... :)


...sajnos nem alkalmas rá túlzottan, tehát célszerű a bonyolultságot alacsonyan tartani.


Ez már régóta nem igaz, én napi szinten írok egészen bonyolultakat és semmi gond nincs velük, egyszerűen csak meg kell tanulni a MySQL jellegzetességeit.
4

Azért. :)

janoszen · 2008. Júl. 6. (V), 08.50
Azért vannak itt durva dolgok. Mint pl a View nem hogy gyorsít hanem lassít, meg egyéb hasonló finomságok. Én áttértem arra, hogy a call stacket minimális magasságon tartom, ha SP-zek, max ha valami kell, akkor megírom magas call stack-kel, majd utána összefésülöm.

Szép és jó a MySQL, de vannak benne apróbb gondol. (PL mikor tervezik implementálni a full joint, stb).
6

ezért? :)

Hodicska Gergely · 2008. Júl. 6. (V), 11.15
Mint pl a View nem hogy gyorsít hanem lassít
Nem értem, hogy ennek mi köze ahhoz, használj-e tárolt eljárásokat, vagy sem. Plusz ez a fenti formában nem igaz, csak az, hogy van amikor rosszabb végrehajtási tervet hoz össze a MySQL view esetén ahhoz képest, mintha a query-ben simán benne lenne a view definiciója.

Én áttértem arra, hogy a call stacket minimális magasságon tartom, ha SP-zek, max ha valami kell, akkor megírom magas call stack-kel, majd utána összefésülöm.
Szerintem ez rossz megközelítés (kivéve ha van valami komoly bibi ezen a téren a MySQL-lel), nem a call stack kéne legyen, ami alapján tervezel. Ez így kb. a korai optimalizálás esete, ami az álmoskönyv szerinte a gonosztól való. :)

Szép és jó a MySQL, de vannak benne apróbb gondol. (PL mikor tervezik implementálni a full joint, stb).
Itt szintén nem látom, hogy ez hogy jön a tárolt eljárásokhoz, de még attól függetlenül sem az a killer feature. Nem is tudnám hirtelen megmondani, hogy utoljár mikor lett volna ilyesmire szükségem, de akkor is egy unionnal simán megoldható.


Üdv,
Felhő
8

Általánosságok

janoszen · 2008. Júl. 6. (V), 12.01
Mondhatnám, hogy általános dolgokról van szó, tárolt eljárásokkal is próbálkoztam jópárszor; az előnyük igazából akkor mutatkozott meg, amikor oda-vissza kellett volna adatot küldeni több, egymás utáni querynél, de ilyen esetben, amikor egyetlen egy queryt kellene lefuttatni, nem biztos, hogy érdemes eröltetni a tárolt eljárást. Arra emlékszem, hogy amikor valami hasonlót próbáltam, akkor valamibe beleütköztem, de meg nem mondom így fél év távlatából, hogy mibe. Ha lesz időm, lehet, hogy utánanézek, de per pillanat bent ülök egy szerverteremben és raid resync statisztikát nézek. :)
2

mysql bug

virág · 2008. Júl. 6. (V), 06.31
Szia,

hányas verziójú MySQL-t használsz? :) Egy időben volt egy ilyen bug benne, mert ennek a hibaüzenetnek itt nem szabadna "fellépnie", ugyanis nincs rekurzió. Ezt a hibát a következő környezeti változó beállításával lehet orvosolni:

set @##kukac##global.max_sp_recursion_depth=255;

Még régebben pedig nem lehetett triggerből sp-t hívni, de ez már nagyon rég volt.
5

Köszi a válaszokat

aspirany · 2008. Júl. 6. (V), 10.55
5.0.51b; tegnap előtt válltottam 5.0.27-ről. igen Én is így tudtam,gondoltam megpróbálkozom vele;
Tehát elvileg működnie kellene a kódnak.

Más.

Felhasználók által elvégzett műveleteket kellene loggolnom adatbázisba. Pl insert update delete;
7

trigger

Hodicska Gergely · 2008. Júl. 6. (V), 11.19
Triggerrel simán meg tudod oldani.


Üdv,
Felhő
9

példa

aspirany · 2008. Júl. 6. (V), 12.56
Esetleg tudnál egy példát mutatni

Köszi a segítséget.
10

példa trigger

Hodicska Gergely · 2008. Júl. 6. (V), 13.47
DELIMITER ;;

DROP TRIGGER IF EXISTS tablename_log_insert;;
CREATE TRIGGER tablename_log_insert
	AFTER INSERT ON tablename FOR EACH ROW
BEGIN
	INSERT INTO /*trigger@tablename_log_insert*/
		log/*t*/
	SET
		entity_id  = NEW.id,
		tablename  = 'tablename',
		activity   = 'insert',
		creator_id = @CURRENT_USER,
		created_at = NOW(),
		log_msg    = CONCAT_WS(',', NEW.important_field1, NEW.important_field2);
	END IF;
END;;

DELIMITER ;
Valami ilyesmi jó lehet neked (nem tesztelve, csak vázlat). Az első /**/ részt azért szoktam, hogy ha egy query bajt csinál, akkor egyből lehessen látni, hogy ki futtatja, hova tartozik (pl. PHP esetén: /* ".__FILE__."##kukac##".__LINE__." */). A másodikat meg azért szoktam, mert gyakran kell rákeresni egy tábla nevére, és néha van annyira általános, hogy nehéz kiszűrni fals találatokat, így viszont ez nem gond.

Magát az insertet kiteheted egy tárolt eljárásba, és akkor a triggereid kb. csak illesztések a loggolandó tábla és a log tábla között. A @CURRENT_USER meg mondjuk úgy kaphat értéket, hogy beleteszed a DB layeredbe, hogy kapcsolódáskor automatikusan beállítja az aktuális user azonosítójával.


Üdv,
Felhő
11

nagyon köszi!!!!

aspirany · 2008. Júl. 6. (V), 14.59
nagyon köszönöm a segítségedet.Jól működik