Trigger

[Honza Pazdziora]

On Tue, Jun 29, 2004 at 01:06:31PM +0000, David Rohlicek wrote:
> Hmm, to by asi resilo. Zkusim. Ja zil v predstave, ze kdyz pouziju:
> BEGIN => INSERT => END Tak mi trigger tikne az po ENDu, ale on tika uz
> po INSERTu. V te me aplikaci, ktera reaguje na trigger musim pouzit 2x 
> SELECT a
> pri tom druhem SELECTu mi to vrati jiz radek OK.
> Nevim jestli je toto spravne chovani DB nebo ne. ????

Trigger samozrejme musi byt spusten v tom okamziku, kdyz se zpracovava
dany prikaz (a to budto na urovni prikazu nebo jednotlivych zaznamu).
Pokud totiz udelate trogger, ktery bude delat

	new.jmeno := lower(new.jmeno);

tak potrebujete, aby tato operace byla triggerem provedena, proste
proto, ze v nasledujicich selectech v te same transakci chcete videt
vysledek toho selectu.

Ten problem je v tom, ze UDP nebo zapis do FIFO jsou veci mimo
transakcni system. Takze se stanou, druhy proces na zaklade nich zacne
cist, ale teprve at prvni transakce provede commit, tak budou zmeny
viditelne.

Neni to tedy tak, ze musite pouzit select dvakrat -- je to tak, ze jich
klidne muzete pouzit dvacet a nic se nemusi stat, nebo ze prvni aplikace
stihne provest commit jeste pred prvnim selectem.

Reseni je pouzivat primo nastroje databazoveho serveru, ktere dovoluji
asynchronni zasilani zprav prave az pri commitu. Mene hezke ale stale
funkcni reseni je opakovane cist tabulku, do ktere Vam prvni aplikace
zapise id zmeneneho zaznamu, a po zpracovani odtamtud to id smazat
nebo si jinak poznamenat, ze uz jste zmeny zpracoval.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.