5. Clause From

5. Clause `From`

5.1. Définition des entités

Dans un premier temps, la clause From doit donner la liste des entités sur lesquelles la requête doit être exécutée. Dans tous les cas, on doit donner au moins une entité. Une entité peut être désignée par le nom complet de sa classe, ou son nom, qui joue le rôle d'alias. Ce nom est la valeur de l'attribut name de l'annotation @Entity. Rappelons enfin deux choses :

une classe annotée @MappedSuperClass n'est pas une entité, on ne peut donc pas faire de requête dessus ;
il est parfaitement possible de faire une requête sur une classe abstraite.

5.2. Jointures dans la clause `From`

Prenons un modèle composé de trois classes : Personne, étendue par Marin et Capitaine. Ces trois classes sont concrètes, et sont des entités. Une quatrième classe, Bateau, porte une relation passager, de type Personne, annotée @OneToOne, et une deuxième, equipage, également de type Passager, annotée @OneToMany On remarquera que cet exemple porte une relation polymorphique ( passager peut recevoir des instances de nos trois classes Passager, Marin et Capitaine. On choisira une strategie JOINED pour la mise en base.

5.2.1. Jointures naturelles

On peut exprimer une jointure de plusieurs façons dans une requête JPQL, tout comme en SQL. La première façon peut être implicite ou explicite. Supposons que l'on cherche le passager d'un bateau dont le nom est passé en paramètre.

Exemple 43. Une première jointure JPQL implicite

select bateau.passager 
from Bateau bateau 
where bateau.nom = :nom

Cette requête JPQL se traduit en EclipseLink par une commande SQL qui comporte une jointure ( left outer join) entre la table Bateau et la table Personne. Si l'on n'avait pas ajouter la clause where, on aurait obtenu en résultat la liste de toutes les personnes qui sont passagers d'un bateau. On aurait pu écrire une jointure explicite de la façon suivante :

Exemple 44. Une première jointure JPQL explicite

select personne 
from Bateau bateau 
	join bateau.passager personne 
where bateau.nom = :nom

Ces deux écritures sont équivalentes du point de vue JPQL, et génèrent le même code SQL dans EclipseLink.

5.2.2. Jointures externes

Comme en SQL, les jointures externes permettent de préserver l'existence des entités du côté gauche de la jointure, quand bien même ces entités n'auraient pas d'entité jointe. Une jointure externe s'exprime de la façon suivante. Comme exemple, écrivons une requête qui permet d'afficher la liste des bateaux et de leurs passagers.

Exemple 45. Une jointure externe JPQL

select bateau 
from Bateau bateau 
	left join bateau.passager personne 
where bateau.nom like :nom

Le SQL généré par EclipseLink est le suivant :

Exemple 46. SQL généré par une jointure externe JPQL

SELECT t1.ID, t1.NOM, t1.PASSAGER_ID 
FROM BATEAU t1 
     LEFT OUTER JOIN PERSONNE t0 ON (t0.ID = t1.PASSAGER_ID) 
WHERE (t1.NOM LIKE ?)

On constate que l'on a bien une jointure externe générée, qui nous permettra d'obtenir toute la liste des bateaux, quand bien même ils n'ont pas de passagers. Si l'on retire le mot-clé left de notre requête JPQL, on obtient le code généré suivant :

Exemple 47. SQL généré sans jointure externe JPQL

SELECT t1.ID, t1.NOM, t1.PASSAGER_ID 
FROM PERSONNE t0, BATEAU t1 
WHERE ((t1.NOM LIKE ?) AND (t0.ID = t1.PASSAGER_ID))

Dans ce cas EclipseLink nous génère une jointure interne, et ne sortiront dans notre requête que les bateaux qui ont un passager.

5.2.3. Jointures de type `fetch`

Ces jointures sont propres au JPQL, cette notion n'existe pas en SQL. Elles permettent de charger explicitement la relation d'une entité, même si les objets de cette relation ne font pas partie du résultat de la sélection. Cela permettra de faire l'économie de la lecture de ces objets en relation lors de l'exploitation du résultat. Si l'on reprend notre exemple JPQL précédent, on constate que seule la clé primaire de notre passager est présente dans la requête. Lors de l'exploitation de cette requête, si l'on en vient à lire ce passager, une demande devra partir sur le cache de l' entity manager . Si le cache ne possède pas l'objet, alors il faudra aller le lire en base, ce qui impliquera un aller et retour supplémentaire avec la base. La jointure fetch permet de lire les objets en relation directement, et donc de faire l'économie de cet aller et retour. Modifions notre requête afin de mettre en œuvre cette technique.

Exemple 48. Jointure fetch

select bateau 
from Bateau bateau left join fetch bateau.passager 
where bateau.nom like :nom

Remarquons tout d'abord deux choses :

le mot-clé fetch se place à droite du mot-clé join ;
on ne peut plus poser d'alias sur le champ à droite du join.

Enfin, notons que ces jointures ne sont pas autorisées dans des requêtes imbriquées. Voici le SQL généré par EclipseLink pour cette requête :

Exemple 49. SQL généré pour une jointure fetch

SELECT t1.ID, t1.NOM, t1.PASSAGER_ID, 
       t0.ID, t0.DTYPE, t0.PRENOM, t0.NOM 
FROM BATEAU t1 LEFT OUTER JOIN PERSONNE t0 ON (t0.ID = t1.PASSAGER_ID) 
WHERE (t1.NOM LIKE ?)

On constate que les champs de Personne ( nom et prenom) ont été ajoutés à la requête, ce qui va autoriser la construction de la relation passager de chaque instance de Bateau dès l'exécution de cette requête.

5.3. Remarque finale sur les jointures en JPQL

On prendra garde que le fait d'écrire une jointure dans une requête JPQL contraint le résultat a posséder un résultat pour cette jointure, quand bien même on n'utilise pas l'entité en relation dans la clause where, même dans le cas où cette clause where n'existe pas. Considérons par exemple la requête JPQL suivante.

Exemple 50. Requête jointe sans clause where

select bateau 
from Bateau bateau 
     join bateau.passager personne

Bien que cette requête ne pose aucune condition sur la relation passager, la jointure sera établie dans le SQL généré. En particulier, si aucune instance de Personne ne se trouve en base, aucun bateau ne sera sélectionné par cette requête.

JPA & EJB

Retour au blog Java le soir

Cours & Tutoriaux