Zend FR

Apparemment ce n'est pas possible avec Zend\Db (j'ai regardé un peu le code des classes utilisées lors d'un select et ça n'a pas l'air de pouvoir retourner un tel résultat). Peut-être en utilisant l'hydrator du lien que j'ai fourni précédemment, mais je n'arrive pas à comprendre comment l'utiliser dans mon cas, c'est pas assez clair.
Pour contourner le problème j'appelle à nouveau mon hydrator dans la classe du premier objet, qui va remplir le "sous-objet". Ça fonctionne pour les relations OneToOne, et pour les OneToMany je ferai 2 requêtes (de toute façon c'est le mieux à faire lors d'une telle relation, d'après ce qu'on m'a dit).

J'ai appris à appeler le ServiceManager, dans les classes"invokables" de celui-ci, grâce à l'implémentation de ServiceLocatorAwareInterface.
Ça m'arrive souvent de l'utiliser dans d'autres classes, mais j'ai peur d'en abuser. Si j'ai besoin d'utiliser uniquement le SM dans une classe, c'est mieux d'utiliser la factory ou d'implémenter la classe de ServiceLocatorAwareInterface ?

Orkin a écrit:

Par contre ne l'utilises pas dans tes modèles !!

Comment faire dans mon modèle dans ce cas ? Je n'en ai pas besoin dans mes classes *Table, mais pour mes hydrator si.

Quel est l'avantage de faire une requête plutôt que 2 ? Pour moi 2 ça serait mieux, car par exemple si je veux remplir un objet qui contient une collection d'un autre objet, le résultat de la requête contiendrait N fois le contenu du 1er objet (où N = le nombre d'objets de la collection).

Je peux aussi appeler la classe et instancier mon sous objet directement dans le modèle, mais ça revient à ne pas utiliser le ServiceManager qui contient déjà la référence vers cette classe.

Doctrine utilise les annotations d'après ce que j'ai pu voir, mais j'avoue ne pas aimer cette pratique.
Je pense que je vais finalement me tourner vers Doctrine pour les hydrators tout en gardant Zend\Db pour les tables, formulaires etc (du moins si c'est possible). C'est vraiment pratique de pouvoir générer automatiquement les modèles à partir de la BDD.

Tu n'es pas obligé d'utiliser les annotations pour doctrine, tu as d'autres formats disponibles .

En fait tout dépend de la façon dont tu fais ta requête, c'est là où il faut être exigent sur ton code. Doctrine permet le lazy-loading des données ce qui veut dire que lorsque tu récupères une entité Utilisateur (par exemple) qui a une relation vers Profil qui lui même a une relation vers les Droits sans rien configurer il va faire une requête uniquement pour récupérer le contenu de la table utilisateur ! Donc dans ce cas si tu souhaites récupérer les droits associer à son profil tu vas faire un getProfil() (génère une requête) puis getDroits() (génère une autre requête). Donc tu auras au moins 3 requêtes, ce qui est logique puisque tu lui a pas prévenu que tu voulais récupérer ces infos là à l'origine. Tu ferais pareil sur une application REST avec un appel sur 3 url pour récupérer ces infos si tu n'as pas tout retourné d'un coup.

Donc tu as deux solutions :
- Utiliser un repository où tu vas écrire ta requête en DQL, c'est pratique quand tu as des choses assez complexes à faire
- Renseigner les annotations fetch="EAGER" ta relation ManyToOne, ce qui signifie que doctrine va faire automatiquement la jointure !

Tu peux renommer le sujet, je déplacerais si besoin.

En fait c'est le but de l'orm tu fais plus de SQL à proprement parlé tu récupères un objet donc ça n'a pas forcément de sens de récupérer une entité qu'à moitié remplie. Faut vraiment dissocier ces deux aspects : ORM  et SQL.

Tu peux tout à faire via doctrine écrire une requête SQL et remplir ton objet avec (c'est très fastidieux) mais c'est pas son but. Tu demandes à l'ORM de te retourner une entité en fonction de tel ou tel critère et c'est lui qui sait quoi faire.

Alors sur ce point je ne suis pas du tout d'accord avec toi !!

Seryus a écrit:

Doctrine nous force aussi à modifier notre base de données (obligation d'avoir une clé primaire par table alors que ce n'est pas forcément nécessaire, il ne supporte pas le type enum).

Les clés primaires et étrangères sont là pour que ta base de données garde une certaines cohérence. Certes c'est pas toujours utile d'avoir un id dans le cas d'une table de paramètres avec code => valeur par exemple mais ça ne coûte rien d'avoir un id. A mon sens toute table doit avoir une clé primaire (simple ou composée) donc là dessus doctrine ou hibernate d'ailleurs apportent un peu de rigueur !

Ensuite doctrine se sert des id pour mettre en cache les données. Il est possible d'appeler plusieurs la même donnée depuis la base de données et une seule requête SQL est générée car doctrine l'a récupéré en cache.

Pour ta première remarque tu y as répondu tout seul .

En fait que se soit par annotation ou directement en DQL doctrine fait le même genre de requête dans la mesure où tes annotations sont bien faites. Si tu as besoin d'une jointure et que tu n'as pas mis l'annotation fetch="EAGER" tu auras une requête supplémentaire lorsque tu vas vouloir récupérer cette infos. Là où le DQL est important c'est lorsque que tu n'as pas toujours besoin de cette jointure, tu ne peux donc pas te contenter d'une annotation. Le DQL s'écrit plus vite que le SQL mais c'est un détail et tu restes dans un esprit orienté objet ce que tu n'as pas en SQL.

Le gros avantage d'un ORM c'est d'apporter une couche d'abstraction à ta base de données. Si aujourd'hui tu as une base de données MySQL et que demain tu passes sur de l'Oracle tu n'as rien à faire à par changer le driver jdbc c'est tout. Chaque SGBD a ses propres fonctions et ses spécificités que tu peux complètement abstraire grâce à l'ORM. Ca permet aussi à des développeurs qui ne connaissent rien au SQL (si si ça existe) de pouvoir en faire.

C'est aussi le but de Zend\Db normalement. Là où ça diffère c'est qu'avec le DQL t'as pas à te soucier de savoir sur quel champ faire ta jointure etc ... Tu lui dis que tu veux récupérer tel champ de ton objet (qui est une relation) et hop il fait tout tout seul.

Rien ne t'empêche d'utiliser Zend\Db plutôt que Doctrine hein .

Bonjour,

Je remonte le sujet car je suis de nouveau tombé sur le 1er problème que j'avais (où l'élément Select ne vérifiait pas si le choix était bien dans la liste), je sais d'où ça vient, mais je n'arrive toujours pas à le corriger.

Par défaut, les éléments de formulaires ont des validateurs inclus. L'élément Select possède par défaut le validateur "InArray" qui vérifie que le choix est bien dans la liste des options (setValueOptions).
Le problème que j'ai, apparait lorsque je spécifie un validateur pour mon élément Select dans la fonction "getInputFilterSpecification", les validateurs par défaut sont écrasés par les validateurs que j'ai spécifié.
Ici je voulais juste modifier le validateur par défaut "required" pour le mettre à "false" (car par défaut il est à "true") mais ça écrase tous les validateurs par défaut de l'élément Select (y compris le "InArray" bien utile) !

Comment corriger ce problème ?

Tout simplement

[lang=php]
public function getInputFilterSpecification()
{
    return array(
        'elementName' => array(
            'required' => false
        )
    );
}

dans mon fieldset

Non pas de message d'erreur.
J'ai copier/coller le code de la doc sur les fieldset en l’adaptant au mien, j'ai toujours le même problème.

Un required à true m'enlève aussi les validateurs de base.

As-tu essayé avec l'élément Select de ZF2 ?

Orkin a écrit:

PS : tu as quand même des problèmes bizarres !

Oui malheureusement, je m'en passerais bien

J'ai essayé un copier/coller du code de la doc sans le modifier (à part le rajout de required à false sur l'url dans la fonction "getInputFilterSpecification") dans un nouveau module et le même problème est présent. Ça ne vient donc pas de moi non ?

Sinon je peux passer de nouveau le validateur "inArray", mais ça fait pas très propre je trouve. Je le supprime (malgré moi) pour le remettre et je dois aussi gérer l'option à null.
Je m'en contenterai quand même pour le moment

Edit : Pour ceux qui aurait ce problème, on peut le contourner ce "bug" avec :

[lang=php]
$formulaire->getInputFilter()->get('monElement')->setRequired(false);

une fois le formulaire instancié. C'est mieux que de repasser chaque validateur à l'élément

Dernière modification par Seryus (05-03-2014 10:28:56)