mais je pars du postulat, peut être faux après tout, que ces outils de mapping n'offrent pas une bonne visibilité sur le SQL généré ou que ce dernier est trop générique pour être raisonnablement optimisé ...
Il n'est pas générique, absolument pas.
Le truc c'est simplement de pouvoir écrire, par exemple si on prend l'exemple d'Hibernate, un ordre simple comme (genre) :
Dossier d = getJdbcTemplate().load(12,Dossier.class);
où 12 est la clé primaire du Dossier recherché.
Dans le fichier de mapping, on a décrit par exemple que :
Les objets Dossier sont stockés dans la table TDOSSIER
L'attribut id est stocké dans la colonne ID
L'attribut numero est stocké dans la colonne C-NUM
L'attribut Libellé est stocké dans la colonne N-LIB
Hibernate va alors fabriquer la requête :
1
2
|
SELECT d.id, d.c-num,d.n-lib FROM tdossier d WHERE d.id = 12 |
C'est tout.
Il n'y a rien, absolument rien de générique. Tout peut être anticipé en fonction du mapping.
L'idée du langage HQL d'Hibernate, qui est très très proche de SQL, est simplement de permettre de nommer les noms Java des objets/attributs à la place de leur correspondant SQL. Cela permet avant tout l'écriture d'un code "SQL" (HQL donc) proche du fonctionnel mais qui finalement ressemble à ce que l'on aurait écrit en SQL natif.
Dans des cas avec jointures nécessaire, il suffit aussi de faire la jointure en "objet" en mettant une clause where avec égalité des 2 clés primaires des objets et s'il y a une table de jointure, Hibernate génèrera la requête SQL adéquate.
Bref, il n'y a rien de générique ni de magique, tout est régit par le fichier de mapping.
D'ailleurs, il est possible d'activer les traces SQL afin, notamment lors des tests, de demander à logger les ordres SQL effectivement envoyés.
Dans ces cas plus complexes, on peut parfois même être étonné de l'ordre généré qui est mieux foutu que ce que l'on imaginait faire "à la main".
0 |
0 |
) qui peuvent se prononcer, ça serait encore mieux
Envoyé par Ricky81
)