Dotaz: SLQ dotazy jen jako

[Dědek]

Ahoj, neví někdo jak se jmenuje ta funkce které provede sql dotaz ale fyzicka data nevloží, nepřepíše, nesmaže atd.. jen vrátí jestli je všechno ok a požadovaný sql dotaz jde bez chyby vykonat.. Díky za pomoc

Odpovědi

[Pavel Stárek]

Nevím tedy v jaké databázi, ale na to je asi dobré použít transakce. V MySQL třeba takto: http://dev.mysql.com/doc/refman/5.1/en/commit.html

[kuka]

A v jakem prostredi by "ta funkce" mela byt?

[Dědek]

Acho jo, omlouvám se. Jedná se o MYSQL a bylo by to voláno z PHP

[Sten]

EXPLAIN dotaz

[Dědek]

Jako takto?

$sql = EXPLAIN . "UPDATE table SET status = 999 WHERE user = 1";

mysql_query($sql);

[Jendа]

PHP Notice:  Use of undefined constant EXPLAIN - assumed 'EXPLAIN' in - on line 2

V PHP dáváme řetězce do "", jinak může jít o konstantu.

[Sten]

$sql = "EXPLAIN UPDATE table SET status = 999 WHERE user = 1"
$result = mysql_query($sql);

Kromě simulace toho příkazu vám to ještě řekne, kolik dat by se změnilo, jaké klíče a jaké tabulky by se použily a vůbec jak optimální ten dotaz je.

[smajl]

nastavit mysql aby automaticky ne-COMMITovalo transakcie -> SET autocommit=0;
zacat transakciu -> START TRANSACTION
spustit query (select/update/insert/...)
zaznamenat vysledok query (netusim ci chcete validovat spravnost prikazu alebo zistovat ci dany prikaz ovplyvni XY zaznamov)
zrusit transakciu -> ROLLBACK

[kuka]

Problem je samozrejme v tom, ze tazatel nespecifikoval, co vlastne chce. Nicmene toto je hodne drsny zpusob, jak neco overovat, a to nejen z hlediska vykonu. A v principu toho moc neresi, protoze po rollbacku a overeni, ze je "vse v poradku" to znovu uz probehnout nemusi. Kazdopadne potreba overeni "ze to projde" je sama o sobe podezrela a obvykle ukazuje na nepovedeny query factoring apod.

[Dědek]

No potrebuji asi tohle...

1 ulozim do mysql data
2 poslu oznameni na email
3 ulozim do mysql jina data
4 uložim do mysql jeste jina data

pokud s techto 4 moznosti selze je cely proces uplne k nicemu, proto jsem to chtel nejak osetrit.

[kuka]

Aha. A co tedy s tim odeslanym emailem, kdyz sleze bod 4? Musis si rozmyslet vsechny scenare a pak se da bavit o technologickem reseni. Napriklad pokud mezi temi body nejsou zadne prodlevy, tak by asi bylo lepsi poslat email az na konec, stejne pravdepodobne nedojde driv, nez ty operace na databazi skonci. Ostatne doruceni mailu nejde bez akce na strane adresata nijak overit, takze je obvykle uplne jedno, kdy se odesle.

[Dědek]

To je úplně jedno kdy se odešle, stejně to nevyřeší ostatní problémy. Co když selže ukládání bod 4? Co s těma 3 předchozíma v mysql, budou k ničemu :(

[kuka]

Na to se muze pouzit transakce, tzn. bud se provede vsechno, nebo nic, to databaze umi. Co nikdo neumi je vzit zpet odeslani mailu, proto zalezi na tom, kdy se v celem procesu odesle.

[Ivan]

Jednoduse. Misto toho aby mail "odeslal", tak ho vlozi do fronty (fronta = tabulka v DB) a z ty fronty to asynchronne vyzvedne dalsi proces. Takhle to delaji databaze, ktere maji podporu pro SMTP.

[kuka]

No a to je to co jsem radil, odesle se to proste az na konci. Podstatne je, ze skutecne poslani mailu nejde "odrolovat". Bud s nim pockam a jen si ho poznamenam (coz neni odeslani mailu), ale pak nevim, jestli se mi nakonec povede, nebo ho udelam, povede se, ale pak uz ho nezrusim. Jesli na to pouzivam tabulku v databazi nebo neco jineho na to nema vliv.

[Filip Jirsák]

Přesně k tomuhle se používají transakce. V případě transakce přes víc prostředí pak transakce s dvoufázovým commitem.

[l0gik]

Jenže principiální problém je v tom, že odeslání mailu nejde verifikovat nikdy. V tom případě se mi zdá nejlepší řešení se tvářit, jako že ten mail poslat jde vždy.

[Filip Jirsák]

Odeslání e-mailu verifikovat jde, záleží na tom, jak nadefinujete odeslání e-mailu. A třeba definice „lokální MTA převzal e-mail do své fronty“ je pro většinu případů použitelná.

[l0gik]

Jenže takováto informace je naprosto k ničemu. Úplně stejně mohu tento mail převzít do fronty v databázi: zaručuje mi to naprosto stejnou šanci, že mail bude odeslán, ale zároveň neztratím výhodu jedné transakce.

[Filip Jirsák]

Šance na odeslání z nějakého rozumného MTA bude asi přeci jen větší (databáze nebývají tak vyladěné a otestované pro odesílání e-mailů jako poštovní programy). Výhodu jedné transakce neztrácím ani při použití fronty MTA, transakce přece nemusí být čistě databázová. Fronta v databázi je samozřejmě také možné řešení, ale pro tento případ je nejspíš zbytečně složité. Tady stačí začít transakci, provést SQL příkazy, odeslat e-mail, a když se vše podaří, transakci do DB commitnout.