PDO : Quel intérêt du pdo::param_* dans un bindValue() -> Requête préparé [Résolu]

[Ghostaunt]

Bonjour, bon bon petite question du soir :)

Cet après midi j'ai effectué quelques test, pour voir l'utilité de PDO::PARAM_INT/PDO::PARAM_STR/PDO::PARAM_BOOL etc.
Je me suis dit, "ah tient je vais essayer de faire passer une chaine de caractère tout en lui imposant un PDO::PARAM_INT", et au final, ça passe quand même.

Alors j'aimerais savoir a quoi sert réellement cet attribut ? Car sans, ça reviens au même, mais je dois me tromper ? :o

exemple d'utilisation :

Code :

1
2
3
4
5
6
7
8
9
10
11
<?php
/* Exécute une requête préparée en associant des variables PHP */
$calories = 150;
$couleur = 'rouge';
$sth = $dbh->prepare('SELECT nom, couleur, calories
    FROM fruit
    WHERE calories < :calories AND couleur = :couleur');
$sth->bindValue(':calories', $calories, PDO::PARAM_INT);
$sth->bindValue(':couleur', $couleur, PDO::PARAM_STR);
$sth->execute();
?>

source : http://www.php.net/manual/fr/pdostatement.bindvalue.php

[sabotage]

C'est au cas ou le sgdb le gère.

[Ghostaunt]

Merci pour ta réponse, mais peux tu m'en dire un peu plus ?

[julp]

Ça a tout son sens pour des clauses comme LIMIT, par exemple (un bind en non int, déclenchera une erreur de syntaxe).
Et encore faudrait-il ne pas se baser sur une expérimentation sur des pilotes PDO mal-conçus ou "spécifiques". Exemple : celui de MySQL, qui considère avant tout le type de la variable PHP plutôt que la constante PDO::PARAM_* (bien qu'en réalité ce soit un peu plus complexe, car la base - pdo - peut d'abord assurer une partie du travail sur la base de la constante - conversion vers string notamment).

Illustration :

Code :

1
2
3
4
5
6
$select = $dbh->prepare('SELECT * FROM utilisateurs ORDER BY login ASC LIMIT :offset, :row_count');
// ...
$select->execute(array(..., 'offset' => 10)); // bindé comme string : erreur de syntaxe
$select->bindValue('offset', 10/*, PDO::PARAM_STR*/); // idem
$select->bindValue('offset', $_GET['offset'], PDO::PARAM_INT); // insuffisant, serait bindé comme string (toute variable externe est une chaîne)
$select->bindValue('offset', intval($_GET['offset']), PDO::PARAM_INT); // cast nécessaire pour pdo_mysql pour avoir un type int à la base

[Ghostaunt]

Bonsoir et merci, tes exemples sont compréhensible mais ça ne me réponds pas trop à ma question.

Dans ce cas là :

Code :

$select->bindValue('offset', intval($_GET['offset']));

Est-ce qu'il fonctionnerais ? Si on met le intval, je trouve un peu inutile de préciser le bindParam_INT ?
Peux tu m'expliquer ceci ?

[julp]

Non, ça, ce serait bindé comme une string, quel que soit le SGBD. A cause de la valeur par défaut du troisième paramètre (PDO::PARAM_STR - cf doc). Et, comme je le disais, c'est l'extension pdo même qui ferait alors la conversion vers string.
1. Tout d'abord, pdo, du fait du type indiqué PDO::PARAM_STR effectuerait la conversion en string
2. Ensuite, passant après, le pilote (pdo_xxx) ne verra donc pas un type int mais string, pour la donnée, qu'il respectera

Code C :

1
2
3
4
5
6
7
8
static int really_register_bound_param(struct pdo_bound_param_data *param, pdo_stmt_t *stmt, int is_param TSRMLS_DC)
/* ... */
if (PDO_PARAM_TYPE(param->param_type) == PDO_PARAM_STR && param->max_value_len <= 0 && ! ZVAL_IS_NULL(param->parameter)) {
/* ... */
	convert_to_string(param->parameter);
/* ... */
 
/* puis transmission au pilote */

Justement, en théorie, ce n'est pas [le type de] la valeur PHP qui dicte le type SQL mais bien la constante PDO::PARAM_* indiquée en troisième paramètre. Après ça dépend du SGBD, de son API et de comment est codé le pilote.

[Ghostaunt]

D'accords, je viens de faire un petit test, et dans mon gdbd la convertion ce fait toute seule apparemment, même qu'il y est un param_str.

Merci pour ces explications !