Dotaz: php a náhrada die

[Jarek]

Ahoj, jak můžu nahradit tohle

mysql_query($sql) OR die("Chyba!");

nevím co je dobře

$mysql_query = mysql_query($sql);
if(!$mysql_query) {
# chyba
}

nebo

$mysql_query = mysql_query(($sql),0);
if($mysql_query ==0) {
# chyba
}

nebo

$mysql_query = mysql_query(($sql),0);
if($mysql_query === false) {
# chyba
}

poradíte?

Děkuji

Odpovědi

[Jendа]

Podmínka je u všech příkladů stejná (až na ty tři = u posledního).

Jaké parametry chceš nakrmit mysql_query() musíš vědět sám. Pokud máš současně vždy jen jedno spojení s databází, nemusíš druhý parametr uvádět.

[Tarmaq]

if (!$resource = mysql_query($sql)) {
  #chyba
}

[Kit]

if(!$result=mysql_query($sql)) throw new Exception("Chyba!");

[Josef Kufner]

Return Values

For SELECT, SHOW, DESCRIBE, EXPLAIN and other statements returning resultset, mysql_query() returns a resource on success, or FALSE on error.

For other type of SQL statements, INSERT, UPDATE, DELETE, DROP, etc, mysql_query() returns TRUE on success or FALSE on error.

Takže správně je:

$result = mysql_query($query, $connection);
if ($result === FALSE) {
   // Chyba
} else {
   // Uspech
}

Pak je otázkou, zda je chyba vážná nebo ne. Pokud děláš select, tak tam asi budeš chtít pomocí error_log() zaznamenat detaily o chybě. Pokud to je insert/update, tak jsi třeba jen narazil duplicitou na unikátní klíč a 'chyba' je vlastně v pořádku.

Ale asi nejlepší je použít nějakou nadstavbu, třeba dibi.

[Šangala]

To není tak úplně třeba, protože nic jiného co by se vyhodnotilo jako FALSE (0,'', NULL…) to vrátit nemůže, buď je to resultset, nebo TRUE nebo FALSE.
Něco jiného by to bylo například u mysqli_fetch.

[Josef Kufner]

To sice jo, ale je to spíš náhoda, než že by se na to dalo spolehnout. Pokud se v dokumentaci píše, že to vrátí FALSE, tak tam patří '==='. Je to celkem častý zdroj chyb, které se těžko hedají.

[xkucf03]

Doporučuji použít PDO – je univerzálnější (ne jen pro MySQL). Pak to bude vypadat nějak takhle:

try {
	$dotaz = $pdo->prepare($sql);
	$dotaz->execute();
	$r = $dotaz->fetchAll();
	/** uděláme něco s výsledkem */	
} catch (PDOException $e) {
	/** uděláme něco s chybou */
}

A před execute() ještě nastavíš parametry dotazu (nebudeš je vkládat do textu SQL):

$dotaz->bindParam($parametr, $jehoHodnota);

$parametr je buď pořadí (od 1) nebo název parametru – do SQL dáš třeba

SELECT * FROM tabulka WHERE id = :nazevParametru

nebo tam dáš jen otazník a odkážeš se na parametr podle jeho pořadí.

[Josef Kufner]

Na sestavování selectů je povětšinou potřeba něco mnohem mocnějšího. Připravené dotazy ti nepomůžou s přidáváním podmínek, když chceš filtrovat podle různých kritérií při různém použití dotazu.

Dibi fluent:

$q = dibi::select('t.id, t.name, t.address')
     ->from('`table` t');
if ($show_last_month_only) {
     $q->where('t.mtime > NOW() - INTERVAL 1 MONTH');
}
if ($city != '') {
     $q->leftJoin('`address` a')->on('a.id = t.address');
     $q->where('a.city = %s', $city);
}
if ($count > 0) {
     $q->limit($count, $offset);
}

Jakpak by to asi vypadalo, kdyby se lepily kousky stringů dohromady? A jak by se takový slepenec rozšiřoval o další možnosti filtrování?

[xkucf03]

To je samozřejmě další stupeň abstrakce a odstínění od „nízkoúrovňového“ SQL (což je v něčem užitečné a v něčem naopak škodlivé). Stejně tak lze poradit ORM typu Hibernate/JPA Ale když vidím, jak tazatel používá funkce typu mysql_query(), tak mi přijde nevhodné přeskočit tolik vrstev a radit rovnou tyhle vysokoúrovňové věci (jednak nejsou vždy tím nejlepším řešením a jednak je lepší, když si tím člověk projde postupně a nepřeskakuje).

Jakpak by to asi vypadalo, kdyby se lepily kousky stringů dohromady? A jak by se takový slepenec rozšiřoval o další možnosti filtrování?

1) Tyhle dynamické (strukturou) dotazy jsou celkem výjimečná věc – ve většině aplikace si vystačíš s SQL, které je vždy stejné a liší se jen parametry (a ty dynamické budeš potřebovat jen v nějakém vyhledávání resp. filtru, kde uživatel zadává různé podmínky).

2) SQL se dá poslepovat z kousků textu, kdy ale lepšíš jen (bezpečné) názvy sloupců a otazníky (nebo zástupky typu :parametr1), ale ne (nebezpečná) data od uživatele – ta tam dostaneš parametrizací dotazu. Pořád je to lepší, než způsob, jakým velká část lidí na webu „programuje“

[Josef Kufner]

Ne, tohle není žádná vyšší abstrakce. To je jen chytřejší cat (spojování stringů), který využívá znalost syntaxe SQL dotazu. Nic víc. Viz kód toho lepení.

Výpisy seznamu položek filtrovaných podle různých kritérií jsou, tedy alespoň na webu, velmi časté. Odhaduju to tak na třetinu dotazů psaných programátorem (pokud nepoužívá nějaké ORM). Většinou se dotazy liší jen málo, střídají se jednoduché podmínky ve where, někdy v kombinaci s triviálním joinem.

[Kit]

Nikde nevidím ošetření chyb, na které se tazatel ptal a které Dibi jistě nabízí. Kromě toho je uvedený příklad na můj vkus příliš komplikovaný a působí spíš jako spam na Dibi než jako řešení selhání dotazu SQL. A že může selhat dotaz i v Dibi, je snad jasné.

[VM]

V PHP lze napsat:

funkce() or die();

ale nelze napsat:

funkce() or moje_obsluha();

Dal jsem jim na to bugreport, ale odmítli se tím zabývat, takže to asi v dohledné době nepůjde.

Mimochodem v PHP je podobných bastů daleko víc, například nedodělané lambda funkce přes create_function() pro array_map() - ve srovnání s předlohou v Perlu toho umí míň, a jsou naimplementované tak špatně, že je v oficiálním manuálu ani nedoporučují používat.

[Tarmaq]

Vazne? Tohle

function foo()
{
    print(__METHOD__);
    return false;
}
function bar()
{
    print(__METHOD__);
    return true;
}
foo() or bar();

mi vypise:

foobar

[Non_E]

Funkce create_function nebyla nikdy povedená. Na druhou stranu se php jako jazyk stále vyvíjí. Zkus od php 5.3 jako callback použít skutečnou anonymní funkci.

Výraz foo() or bar() samozřejmě funguje, nefunguje foo() or throw new \Exception.