Cloud Connected

La question à 2 centimes d’euros du jour : qu’est-ce qu’on obtient comme résultat avec une requête SQL de ce genre de celle ci-dessous (avec un MySQL) ?

select * from ma_table where id = 42 = 0;

La réponse est : toute la table sauf la ligne dont l’id vaut 42 ! En fait, en raison de la précédence des opérateurs, cette requête est équivalente à :

select * from ma_table where (id = 42) = 0

Comme l’opérateur de comparaison = retourne 0 (FALSE) ou 1 (TRUE) (ou NULL si un des 2 arguments vaut NULL), l’expression id = 42 = 0 est parfaitement valide et est équivalente à id != 42.

Mais à quoi ça sert me direz-vous ? A faire des injections SQL dans un site PHP qui ne filtre pas correctement ses variables… A bon entendeur !

Avec MySQL, stocker un booléen (0 ou 1) dans un type enum (plutôt que dans un type numérique comme le ferait toute personne saine d’esprit), est une *très* mauvaise idée, qui fera à coup sûr perdre quelques heures au développeur qui devra maintenir le code. Et voici pourquoi.

Disons que la table qui a été créée ressemble à ça :

create table enum_is_evil (
  id integer not null auto_increment,
  value enum('0','1') not null default '0',
  primary key (id)
);

insert into enum_is_evil (value) values ('0'), ('0'), ('1');

Si on ne fait pas gaffe qu’il s’agit d’un enum et pas d’un type numérique (comme on pourrait logiquement le supposer), voila ce que ça donne…

mysql> select * from enum_is_evil where value = 0;
Empty set (0.00 sec)

Bon, aucun résultat alors qu’on devrait en avoir 2… Essayons autre chose.

mysql> select * from enum_is_evil where value = 1;
+----+-------+
| id | value |
+----+-------+
|  1 | 0     |
|  2 | 0     |
+----+-------+
2 rows in set (0.00 sec)

Youpi ! C’est n’importe quoi !

Et voyons ce qui se passe quand on ne fait pas attention à l’insertion, c’est encore plus drole.

insert into enum_is_evil (value) values (0), (0), (1);

Note : cette requête produit des warnings (logique), mais lorsqu’elle est executée dans un script, il n’y aucune chance de s’en apercevoir.

mysql> select * from enum_is_evil where value = 0;
+----+-------+
| id | value |
+----+-------+
|  4 |       |
|  5 |       |
+----+-------+
2 rows in set (0.00 sec)

Yeah, des valeurs vides dans la table alors qu’on devrait avoir uniquement des 0 ou des 1 !

mysql> select * from enum_is_evil where value = 1;
+----+-------+
| id | value |
+----+-------+
|  1 | 0     |
|  2 | 0     |
|  6 | 0     |
+----+-------+
3 rows in set (0.00 sec)

Encore mieux, la valeur “1″ qu’on a ajoutée est devenue un “0″ !

Conclusion : bien que tout ça soit logique quand on lit la doc du type ENUM (il suffit d’ajouter des quotes autour des valeurs pour obtenir les bons résultats), c’est une source d’erreur potentielle assez vicieuse quand on s’attend à travailler avec un type numérique. Utilisez plutôt un TINYINT !

Dernière partie de ma série consacrée aux modes de récupération de PDO, voici les modes que j’appelle “modificateurs”, car ils ne peuvent pas être utilisés tout seuls et se contentent de modifier le comportement d’un autre mode.

Pour utiliser un modificateur, il suffit d’effectuer un “ou” binaire, par exemple :

$results->fetchAll(PDO::FETCH_TRUC | PDO::FETCH_BIDULE | PDO::FETCH_CHOUETTE);

La plupart de ces modes ne fonctionnent pas lorsqu’ils sont définis par la méthode setFetchMode. Ça ressemble a un bug, mais vu que rien n’est documenté, c’est peut-être normal…

More… »

Suite de ma série consacrée aux modes de récupération de PDO, voici les modes “spéciaux”, c’est à dire des modes au comportement particulier, très mal documentés mais souvent très pratiques !

More… »

Suite de ma série consacrée aux modes de récupération de PDO, voici les modes qui permettent de travailler avec des objets.

More… »

PDO propose une quantité assez impressionante de “modes de récupération” (fetch mode) des données. Entendez par là qu’il est possible de personnaliser le comportement des méthodes fetch et fetchAll pour obtenir les résultats des requêtes SQL sous des formes très diverses. Si certains modes sont relativement classiques et ont des équivalents avec les précédents drivers MySQL (mysql_fetch_array, mysql_fetch_row, etc.), d’autres sont totalement inédits… mais très mal documentés ! Et pourtant, certains sont *très* pratiques… J’ai donc décidé d’écrire une série d’articles présentant tous les modes de fetch, leur fonctionnement et surtout leurs performances.

More… »

Voici une petite requête pour MySQL ≥ 5 qui peut être utile si vous cherchez à obtenir la liste des champs d’une table, pour l’exporter en tant qu’entête d’un fichier CSV par exemple.

select group_concat(column_name SEPARATOR ";")
from information_schema.columns
where table_schema = 'DB_NAME' and table_name = 'TABLE_NAME'
group by table_name;

La requête suivant permet d’exporter une table complète en CSV, sans passer par un langage de script (à condition d’avoir la permission FILE).

select *
into outfile '/tmp/foo.csv'
fields terminated by ';' optionally enclosed by '"'
lines terminated by '\n'
from DB_NAME.TABLE_NAME;

Plus d’infos dans la doc de MySQL.

Ruby, contrairement à PHP (mais comme beaucoup d’autres langages), fait la différence entre un tableau (avec des index numériques) et un hash (avec n’importe quel type d’index, mais sans notion d’ordre). Etant habitué à PHP, je me suis heurté au problème suivant : comment afficher un hash dans l’ordre ?

Considerons le code suivant, où le hash contient les éléments indexés par leur id numérique (je n’utilise pas un tableau volontairement, car j’ai besoin de ces id).

hash = {
	1 => "toto",
	2 => "tata",
	3 => "titi",
	4 => "tutu",
	5 => "tete",
	6 => "tyty"
}

hash.each_pair do |key, value|
	puts "#{key} = #{value}"
end

Il va afficher :

5 = tete
6 = tyty
1 = toto
2 = tata
3 = titi
4 = tutu

Ce résultat correspond à la documentation de la classe Hash :

A Hash is a collection of key-value pairs. It is similar to an Array, except that indexing is done via arbitrary keys of any object type, not an integer index. The order in which you traverse a hash by either key or value may seem arbitrary, and will generally not be in the insertion order.

Bref, c’est tout à fait normal, mais pas du tout ce que je recherche. Pour l’afficher dans l’ordre, il suffit en fait de trier et parcourir les clefs du hash :

hash.keys.sort!.each do |key|
	puts "#{key} = " + hash[key]
end

Et on obtient le bon ordre :

1 = toto
2 = tata
3 = titi
4 = tutu
5 = tete
6 = tyty

Youpi ! Bon, on peut toujours critiquer PHP, mais son concept de tableau/hash mélangé et ordonné, c’est quand même bien pratique :-)

Décidemment le modèle objet de PHP n’est pas mon meilleur ami. Après avoir eu la suprise de découvrir que certaines méthodes ne peuvent pas lancer d’exception, voila que $this change mystérieusement de valeur.

Comme le suggère le dollar dans le nom, $this est bien une simple variable. Donc à ce titre elle peut surement être modifiée, non ? Heureusement, la changer par une assignation directe est impossible, et conduira à une erreur fatale. Ainsi, le code suivant affichera l’erreur Cannot re-assign $this.

class ThisIsFun {
	function reassignThis()
	{
		$this = 'something else';
	}
}

$obj = new ThisIsFun();
$obj->reassignThis();

Mais certaines fonctions, comme extract peuvent aussi manipuler les variables (je l’utilise pour exporter certaines variables vers la vue dans le cadre d’une architecture MVC). Résultat, avec un code comme ci-après, $this est modifié…

class ThisIsFun {
	function reassignThis($vars)
	{
		var_dump($this); // object(ThisIsFun)[1]
		extract($vars);
		var_dump($this); // string 'something else' (length=14)
	}
}

$obj = new ThisIsFun();
$obj->reassignThis(array('this' => 'something else'));

Heureusement la modification n’est effective que dans le contexte de la fonction, mais quand même, c’est plutôt étonnant que ça soit possible. Pour l’éviter il faudrait utiliser le paramètre optionnel supplémentaire extract_type qui contrôlle la gestion des collisions.

Du coup je me suis amusé un peu à chercher d’autres moyens de modifier $this, même si je ne sais pas encore trop à quoi ça pourrait bien servir… Allez, avec une référence c’est élégant :)

class ThisIsFun {
	function reassignThis()
	{
		var_dump($this); // object(ThisIsFun)[1]
		$that = & $this;
		$that = 'references are cool';
		var_dump($this); // string 'references are cool' (length=19)
	}
}

$obj = new ThisIsFun();
$obj->reassignThis();

La bonne blague PHP du jour concerne la méthode “magique” __toString, qui est appellée automatiquement lorsqu’un objet doit être converti en chaine de caractère. Pour je ne sais quelle raison, PHP à partir de la version 5.2 retourne une erreur fatale lorsque une exception est lancée depuis cette méthode…

Ainsi, le code suivant n’affichera jamais “Catched”.

class Foo {
	public function __toString() {
		throw new Exception('woupsi !');
	}
}

try {
	echo new Foo();
} catch (Exception $e) {
	echo 'Catched';
}

Au lieu de ça, j’ai le droit à :

Fatal error: Method Foo::__toString() must not throw an exception

Je trouve ça vraiment étonnant qu’une méthode particulière ne puisse pas lancer d’exception, d’autant qu’entre une erreur fatale et une exception je ne vois pas vraiment la différence. Si j’étais mauvaise langue, je dirais qu’il s’agit d’un hack placé là parceque l’implémentation des exceptions en PHP 5 et/ou de la méthode __toString est moisie, mais je ne le ferais pas.

Evidemment, ce n’est précisé nulle part dans la documentation. Il y a d’ailleurs un bug report ouvert depuis l’année dernière (sic) demandant une mise à jour de la documentation pour préciser cette feature…

Bon, comme j’ai vraiment besoin d’utiliser __toString et que j’ai aussi besoin de traiter les erreurs, voici le workaround (pas très propre) que je vais utiliser en attendant de trouver mieux :

class Foo {
	public function __toString() {
		try {
			return $this->functionThatMayThrowAnException();
		} catch ( Exception $e ) {
			trigger_error($e->getMessage(), E_USER_ERROR);
		}
	}
}