FETCH_CLASS, problème de namespace et de casse

Au commencement, un FETCH_CLASS qui ne fonctionnait pas

Alors je vous préviens tout de suite que j’ai résolu le problème de fond rencontré mais que ce dernier a fini par pointer du doigt un comportement pour lequel je n’ai aucune explication à donner. Je m’en remets donc volontiers à vous lecteurs et lectrices !

Ici, je me trouve dans une commande Symfony (3.3.9) qui utilise doctrine DBAL* pour exécuter une banale requête sql. Le résultat de cette requête doit me retourner un array d’objets « Transaction » mais ce n’est pas le cas, le FETCH_CLASS me retourne un array de array.

*  je n’ai pas doctrine ORM sur ce projet

Voici le code fautif dans TotoCommand.php

Ici, le dump final me retourne un array de array façon FETCH_BOTH au lieu d’un array d’objets Transaction. Le débogage m’a amené d’abord à vérifier le namespace passé en paramètre ainsi que son entité correspondante. Mais je suis assez vite revenu sur mon premier étonnement : une AUTRE commande SF avec un traitement quasi identique ne rencontre pas le problème.

Le code opérationnel de TitiCommand.php

Le dump me retourne bien ici un array de Payment, tout va bien mais en dehors de la requête SQL similaire (j’interroge les deux même tables au travers de la même foreign key), ce n’est pas le même type d’objet qui est visé.

Ok donc, il y a une différence probable entre l’entité Transaction et Payment, au niveau des propriétés ou de leur constructeur ?

Quand tout à coup… ! Une erreur de namespace !

J’ai mis un moment à revérifier le namespace passé au fetchMode dans TotoCommand.php mais ça ne m’avait pas sauté aux yeux :
\PaymentsolutionBundle\Entity\Payment
au lieu de
\PaymentSolutionBundle\Entity\Payment

En effet la casse était incorrecte, le répertoire est bien PaymentSolutionBundle/ et la correction à tout de suite résolu le problème !

Bon sang c’était sous mes yeux !

Quand la casse te casse ton fetch_class

Un problème de casse ?

Tout ça pour ça ? Non…ce n’est pas fini !

Si j’écris un petit billet là-dessus c’est vraiment que ça en vaut la peine je pense.

En effet, regardez bien, j’ai la même erreur de casse dans le fichier TitiCommand.php et pourtant le FETCH_CLASS me retourne bien un tableau d’objets.

Donc, j’ai cogité au problème sur le retour du boulot et j’ai cru deviner le problème dans ma petite tête :
Probablement que l’erreur de casse se trouvait au niveau de la déclaration du namespace dans l’entité Payment, se faisant, un matching opérait bien entre le namespace de l’entité et celui passé au fetchMode.

A contrario j’avais donc (toujours hypothétiquement) aucune erreur de casse dans le namespace de Transaction et se faisant, le matching n’opérait pas cette fois (puisque j’avais l’erreur de casse dans le fetchMode de TotoCommand.php). J’ai vérifié mais ce n’est pas le cas, Transaction.php et Payment.php ont tous deux le même namespace correctement écrits.

Le mystère reste entier : la casse est en jeu !

En l’état le problème est « résolu » mais le fait que TitiCommand.php retourne bien un tableau d’objets en dépit de son mauvais namespace n’a trouvé aucune explication pour le moment (j’ai cependant évidemment corrigé son erreur au passage…).

Le mystère reste entier pour moi, il me faut investiguer autour de la casse des namespaces traitées par PDO mais aussi au travers de Doctrine DBAL.

Je laisse matière à investiguer ici http://php.net/manual/fr/language.namespaces.rules.php mais sans oublier DBAL/Driver/ResultStatement.

FETCH_CLASS, problème de namespace et de casse
4 (80%) 1 vote

Partagez cet articleShare on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInDigg thisShare on TumblrShare on RedditEmail this to someone

3 Comments

  1. Et pourquoi ne pas passer par une native query et result set mapping pour rester dans le cadre de doctrine ?

Laisser un commentaire

© 2017 iKonenn

Theme by Anders NorénUp ↑