Développement d'un nouveau module : Cannot execute queries while other unbuffered queries

[ntoug]

Bonjour,

 

Je suis en train de terminer le développement d'une module pour PS1.5.

J'ai suivi le billet de Sarah Lorenzini sur les bonnes pratiques de dev, que je félicite au passage.

 

Je rencontre un problème lors de l'insert en base de données .

L'insert échoue avec le message :

"

Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.

"

 

D'après ce que je comprends, PDO a mis un verrou sur ma table dû à un SELECT précédent sur cette même table (pourtant je ne suis pas dans une boucle) ..

 

 

Difficile de trouver des infos sur ce forum ou Google pour résoudre ce problème, qui me semble basique..

J'ai trouvé 2 pistes :

• déclarer un "PDO::MYSQL_ATTR_USE_BUFFERED_QUERY" .. (je ne sais pas vraiment comment).
  Ce qui me dérange avec cette méthode, c'est qu'on sort des bonnes pratiques pour s'astreindre à utiliser mysql, ce qui va à l'encontre de l'abstraction des couches..
  
• purger cet hypothétique SELECT précédent, pour faire sauter ce "verrou".. sur de vieux topix, on parle de pdoxxx->fetchAll() .. mais cette notation n'existe plus normalement.. j'utilise des getRow(), getValue() ou executeS().. qui je suppose libèrent les tables après leur appel...
  

Ce problème doit apparaitre pour de nombreux développeurs, j'ai du louper un épisode !

 

 

Pour info, l'insert est tout bête :

$reponse_requete_creation_form = Db::getInstance()->execute($requete_creation_form);

[Prestaspirit]

Bonjour,

 

Il faudrait un peu plus de code pour pouvoir t'aider!

[ntoug]

Désolé, je pensais qu'il s'agissait d'un problème générique et pas spécifique à mon code...

 

Mon module faisant 2700 lignes, voilà quelques éléments :

 

Je fais d'abord :

    $requete_shop_count = "SELECT COUNT(*) FROM " . _DB_PREFIX_ . "shop WHERE active = 1;";
   $count_shop = Db::getInstance()->getValue($requete_shop_count);

Si je mets ces 2 lignes en commentaire, l'insert d'après fonctionne..

 

Puis

$requete_creation_form = "INSERT into " . _DB_PREFIX_ . "SELLER_form (`id_form` ,`nb_images` ,`id_category_auto` ,`id_category_user` ,`id_category_default` ,`active` ,`etat` ,`tailleMo`)
				    VALUES (NULL , '" . $_POST["nb_images_form"] . "', '" . $categories . "', '" . $user_categories . "', '" . $_POST["default_category"] . "', '1', '" . $_POST["etat_form"] . "', '" . $_POST["taille_form"] . "');";
$reponse_requete_creation_form = Db::getInstance()->execute($requete_creation_form);
$ID_last_form = Db::getInstance()->Insert_ID();

 

Cet insert ne passe pas tant que le select précédent n'a pas été commenté.

Et :

- oui, il faut prévoir d'échapper ce qui vient du _POST

- oui, il serait mieux d'utiliser la méthode Db::getInstance()->insert();

Mais cela ne résoudra pas je pense mon problème actuel de "PDO unbuffered"....

[ntoug]

J'ai trouvé une solution "temporaire" : J'ai désactivé le cache sur le select initial :

$count_shop = Db::getInstance()->getValue($requete_shop_count,0);

 

Je ne sais pas si c'est la bonne méthode, si quelqu'un a d'autres propositions, je suis preneur !

[ntoug]

Je reviens sur mon problème, car j'ai un autre controller (le front) qui fait une palanquée de SELECT avant ses INSERT..

Je trouve bizarre de devoir désactiver le cache de tous ces SELECT...

Je viens de faire une tentative, en vain, sans doute qu'un appel à une méthode qqpart fait un SELECT dans son coin..

 

Entre temps, j'ai transformé une partie des insert avec la méthode insert(), sans que cela ne résolve mon problème (ce qui était prévisible).

 

J'ai rajouté une trace dans la méthode _getPDO() de la classe DbPDOCore.

Cette dernière fait bien un PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true lors de l’instanciation de l'objet PDO.

Donc le message d'erreur PHP conseille de positionner cette variable.. qui semble déjà positionnée !

 

.. o'scours !

Edited May 29, 2013 by ntoug (see edit history)