[Doctrine] Quel est l'interet ?

Version imprimable

Hello,

Je parcourait les forums quand j'ai vu ceci :

Code:

1
2
3
4
5
6
    $this->club_liste = Doctrine_Query::create()
        ->from("ClubListe a")
        ->leftJoin("a.ClubRegion b")
        ->where('b.slug = ? ', $request->getParameter('region'))
        ->addOrderBy('a.club ASC')
        ->execute();

Mieux, j'ai pas la suite appris qu'il fallait se cogner ceci, pour avoir la possibilité d'écrire l'immondice du dessus.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
ClubListe:
  tableName: club_liste
  columns:
    id:
      type: integer(4)
      unsigned: 1
      primary: true
      autoincrement: true
    no_region:
      type: integer(1)
      notnull: true
     ....
  relations:
    ClubRegion:
      local: no_region
      foreign: 'no'
      type: many
 
ClubRegion:
  tableName: club_region
  actAs:
    Sluggable:
      fields: [region]
  columns:
    'no':
      type: integer(1)
      primary: true
      autoincrement: true
    region:
      type: string(100)
      default: ''
      notnull: true
    nbre:
      type: string(2)
      fixed: true
      default: ''
      notnull: true
    slug: string(255)
  relations:
    ClubListe:
      local: 'no'
      foreign: no_region
      type: one

On apprend aussi, que cet exemple .yml n'est qu'une version light !

Que l'auteur de ces lignes ne soit pas offenser,

mais je ne comprend pas l'intérêt de se taper toute cette config, pour finalement se prendre la tête avec le genre de syntaxe vu dans la quote 0.

Quelqu'un peut il m'expliquer ? Me dire que j'ai loupé un truc.

Merci, a plus

08/01/2010, 14h33
stailer

Rapidement :

sur chaque ligne de résultat tu pourras modifier tes objets et faire des
save() pour mettre à jour ta base (ou delete()) .
En fait chaque ligne trouvée n'est pas un simple tableau mais bien une liaison avec tes objets configurés. C'est très puissant et dans tes résultats tu peux de nouveau chercher des relations etc. Et mettre tes relations à jour sans exécuter aucune requête.

Concernant la config : elle se génère toute seule, en php ou en yml. Une simple ligne de code crée tes classes , propriétés etc.

Enfin, le code de tes requêtes fonctionnera partout : sql server , mysql etc...
Ceci à par exemple l'avantage de faire fonctionner la clause LIMIT sur n'importe quel moteur.

Bref; la c'est vraiment en 10 secondes... il y a pleins pleins d'autres choses à dire : va voir la doc ;)
08/01/2010, 20h06
kaymak

hello,

Merci de la réponse.

Citation:

sur chaque ligne de résultat tu pourras modifier tes objets et faire des
save() pour mettre à jour ta base (ou delete()) .
En fait chaque ligne trouvée n'est pas un simple tableau mais bien une liaison avec tes objets configurés. C'est très puissant et dans tes résultats tu peux de nouveau chercher des relations etc. Et mettre tes relations à jour sans exécuter aucune requête.
Concernant la config : elle se génère toute seule, en php ou en yml. Une simple ligne de code crée tes classes , propriétés etc.
(.. ect)

Oui ça pas de problème, la puissance d'orm ne m'a pas échappé, tu parles à un là à convaincu.

Ce que j'ai du mal à comprendre dans cet exemple, c'est de l'intérêt d'utiliser une telle syntaxe pour écrire du SQL. (De ne pas joindre ces tables tout seul comme un grand ???)

On peut faire exactement pareil avec PDO, la gestion du schéma en moins certes.
Mais si on en vient à parler gestion du schéma, j'aimerais voir comment ils gèrent le delete d"une colonne sur une base de prod, car ce pas anodin comme opération.
Et là, je me sens moins en confiance que dans une utilisation classique (puisque que c'est boite noir).

En plus, là dans l'exemple, comment fait on un binding dynamique qui n'est pas exprimé dans le schéma de table ?
Cela aussi je le fais régulièrement pour m'éviter quelques (10aines de) requêtes.

Parce que c'est une charge supplémentaire à calculer ceci, l'orm (qui dans doctrine me semble dynamique, résolu à la volée), pour générer ta page ...

D'ailleurs à contrario, la description du schéma est très laborieuse à lire, et à rédiger j'imagine. A tel point, qu'il y à quelques points, qu'en tant que non initié de Doctrine, me paraissent très obscure.
Par exemple, ActAs Sluggable.

Je comprends pas trop ton souci sur ce code à taper en PHP qui ressemble finalement beaucoup à du sql.

Encore une fois, c'est du sql, mais pas sur la base : il est sur tes objets.

Prenons cet exemple :
Code:

1 2 3 4 5 6 $this->club_liste = Doctrine_Query::create() ->from("ClubListe a") ->leftJoin("a.ClubRegion b") ... $result = $this->club_liste->execute();
Oui c'est du sql "classique" finalement et ça parait inutile.. mais voilà ce que tu ne pourras pas faire avec pdo "classique" :
Code:

1 2 3 4 5 6 7 8 9 foreach($result as $club) { foreach($club->ClubRegion as $region_club) { $region_club->nom = 'Nouveau nom de club pour rigoler ;)'; $region_club->save(); } }
J'aurai pu ici rajouter les transactions également.

Enfin sur ma classe ClubRegion je peux très bien surcharger le "save" et pourquoi pas faire ceci afin d'éviter un trigger :

(syntaxe de tête)
Code:

1 2 3 4 5 6 public function save() { $this->date_modified = date('Y-m-d'); parent::save(); }
Voilà, je sais pas si c'est ça que tu ne saisis pas. Sinon pour le schéma "illisible", moi perso je ne vais jamais dedans ... quand je change des trucs dans ma base je lance une génération et c'est réglé.

tu as 2 classes pour chaque table :
répertoire models / generated / BaseClubListe
répertoire models / ClubListe

Seul BaseClubListe sera regénéré. On écrit tous les suppléments dans ClubListe

11/01/2010, 21h51
kaymak

Tes exemples sont très bon. C'est juste le rapport cout d'exécution / gain de développement (Maintenance aussi et surtout) qui me parait démesuré.

Car, (de mon petit point de vue bien bas et qui porte pas loin), Que j'utilise un orm ou pas, je vais toujours encapsuler mes appels dans des méthodes.
(Pour éviter la dispersion du schéma).

Hors là, je ne vois pas le plus que m'apporte cette écriture.
(Apparté, le simple fait d'utiliser un orm apporte des possibilité de scaling et mise en cache c'est donc un truc à faire.)
De plus je dois appréhender de nouvelles notions

C'est un peu cela mon souci, le choix de supprimer le SQL ne me semble pas apporter bcp de fonctionnalité (Qu'on me prouve le contraire, j'en vivrais mieux.), c'est lourd. A apprendre, A exécuter(, a ré exécuter !).

Par contre le coup du schéma par RE de la DB c'est pas mal, c'est clair.

A cela j'ajoute l'effet boite noire.

Citation:

Encore une fois, c'est du sql, mais pas sur la base : il est sur tes objets.

Cela change surtout que je n'ai plus à me soucier du modèle et des clefs d'intégrités, puisque tout est objet et encapsulé.
Y'à des plus, Y'à des moins. Mais c'est relatif à l'orm, pas seulement doctrine.

Fin, bon j'aurais bien aimé voir la preuve par B que c'est plus efficace à maintenir.

Une dernière question tout de même, est il possible de requêter une composition d'objet à la volée avec Doctrine ?? (Table A + Table B + Table C = Table D(ynamique))
Ou chaque table est peu ou prou l'équivalent d'un type d'objet à part entière, comme ClubListe, et D un type à part entière.

En tout cas merci pour tes réponses. a plus.
19/01/2010, 22h23
ZeRevo

Citation:

C'est un peu cela mon souci, le choix de supprimer le SQL ne me semble pas apporter bcp de fonctionnalité (Qu'on me prouve le contraire, j'en vivrais mieux.), c'est lourd. A apprendre, A exécuter(, a ré exécuter !).

Le but du jeu de l'ORM c'est de pouvoir travailler sur les objets. L'un des avantages c'est de ne pas se soucier de la forme par laquelle les données sont stockées en base de données. Ainsi avec un ORM on peut changer le mapping sans changer les requêtes ou même changer rapidement de SGBD (en théorie).

Pour la création des requêtes, tu n'as pas à te soucier du champs sur lequel la requête s'effectue et puis tu peux également faire du lazy loading (si c'est autorisé par ton framework, j'ai uniquement une connaissance d'Hibernate).

Un ORM est un outil très puissant qui peut faire chuter les perfs si on l'utilise mal. Un mélange de requêtes objets et de requêtes SQL est conseillé uniquement pour les besoins de performance.
21/01/2010, 13h19
kaymak

Je pense que je devrais jeter un oeil à un schéma hibernate pour avoir une idée plus large.