3. Définition de requêtes

3.1. Requêtes dynamiques

La première façon de créer une requête JPQL consiste à créer une chaîne de caractères qui porte cette requête, et à la passer à la méthode createQuery() de l' entity manager . Cette approche est parfaitement légale, mais elle pose un problème, et comporte un piège. Le problème est que la traduction de la requête JPQL en SQL se fait au moment de la création de l'objet Query, et à chaque instanciation de cet objet. Si la requête est créée dans une servlet, ou dans un EJB, le coût de traitement devra être payé à chaque fois que l'utilisateur fait appel à cette servlet ou à cet EJB. Le piège se trouve dans la façon dont on veut prendre en compte les paramètres de la requête. Supposons que l'on ait la méthode suivante.

Exemple 32. Une (mauvaise) requête dynamique paramétrée

public List<Marin> getMarinByName(String name) {

    Query query = em.createQuery("select marin from Marin marin " + 
                                  "where marin.nom = '" + name +  "'") ;
    
    List<Marin> marins = query.getResultList() ;
    
     return marins ;
}

Cette requête est censée retourner tous les marins dont le nom est passé en paramètre, et c'est ce qu'elle fait. Cela dit, on peut aussi lui passer en paramètre la chaîne de caractères suivante :

Surcouf' and prenom = 'Robert

Et dans ce cas, elle effectue une tout autre requête. Cette attaque, connue sous le nom d'injection de code est très classique, et doit être absolument évitée. Pour cela, JPQL expose une fonctionnalité analogue aux preparedStatement de JDBC.

3.2. Requêtes paramétrées

Il existe deux moyens de paramétrer une requête. Les deux moyens consistent à placer des éléments particuliers dans la chaîne JPQL, puis de donner une valeur à ces éléments. Dans le premier cas ces éléments sont juste numérotés : ?1, ?2, etc... Dans le second cas, ils sont nommés : :nom, :adresse, etc...

3.2.1. Paramètrage numéroté

Voyons tout d'abord le paramétrage anonyme.

Exemple 33. Paramètrage d'une requête, première méthode

Query query = em.createQuery("select marin from Marin marin " + 
                              "where marin.nom = ?1 and marin.prenom = ?2") ;
query.setParameter(1,  "Surcouf") ;
query.setParameter(2,  "Robert") ;

List<Marin> marins = query.getResultList() ;

3.2.2. Paramétrage nommé

Voici la même requête, avec des paramètres nommés.

Exemple 34. Paramètrage d'une requête, deuxième méthode

Query query = em.createQuery("select marin from Marin marin " + 
                              "where marin.nom = :nom and marin.prenom = :prenom") ;
query.setParameter("nom",  "Surcouf") ;
query.setParameter("prenom",  "Robert") ;

List<Marin> marins = query.getResultList() ;

On prendra garde dans cette deuxième méthode : les noms des paramètres sont préfixés par ":" dans la chaîne JPQL, mais ce caractère n'est pas repris lors des appels à setParameter().

3.2.3. Cas particulier des dates

Comme à l'habitude, les objets java.util.Date et java.util.Calendar posent problème en tant que paramètre. De sorte qu'ils soient correctement convertis, il faut ajouter un paramètre à l'appel à setParameter(), qui porte le type temporel dans lequel la conversion doit se faire.

Exemple 35. Paramètrage d'une requête, cas des dates

Query query = em.createQuery("select marin from Marin marin " + 
                              "where marin.dateDeNaissance = :ddn") ;
query.setParameter("ddn", dateDeNaissance, TemporalType.DATE) ;

List<Marin> marins = query.getResultList() ;

Cette méthode existe également dans le cas de paramètres anonymes et numérotés.

3.3. Requêtes nommées

Dans de nombreux cas, les requêtes utilisées sont connues dès la compilation de notre application. JPQL nous offre alors la possibilité de déclarer ces requêtes en tant que requêtes nommées . Ces requêtes nommées sont déclarées dans des annotations, et donc analysées par l'implémentation JPA au chargement de la classe. Elles peuvent donc être converties en code SQL au moment de ce chargement, et ne pas surcharger l'exécution de notre application. Une requête nommée est déclarée dans une annotation @NamedQuery. Cette annotation prend deux attributs : name, qui porte le nom de la requête, et query, qui porte la requête JPQL. Le nom de la requête doit être unique pour une même unité de persistance. Sans que cela soit une obligation, il est donc pratique de le préfixer par le nom d'une entité. Plusieurs annotations @NamedQuery peuvent être regroupées dans une annotation @NamedQueries, qui prend un tableau de @NamedQuery en attribut. Ces deux annotations doivent être posées sur la classe d'une entité JPA.

Exemple 36. Déclaration de requêtes nommées

@NamedQueries({
    @NamedQuery(
        name="Marin.findAll",
        query="select marin from Marin marin"),
    @NamedQuery(
        name="Marin.findByName",
        query="select marin from Marin marin where marin.name = :name"), 
    @NamedQuery(
        name="Marin.countAll",
        query="select count(marin) from Marin marin"),
})
 @Entity(name="Marin")
 public  class Marin  implements Serializable {

	 // reste de la classe
}

Remarquons plusieurs choses sur cet exemple. Tout d'abord, nous avons donné un nom explicite à notre entité : Marin. Sans cela, il aurait fallu utiliser le nom complet de la classe Marin dans nos requêtes JPQL. Les annotations @NamedQueries doivent être posées sur la classe d'une entité. Rien ne dit que ces requêtes doivent nécessairement retourner des instances ou collection d'instances de ces entités. Il est simplement pratique, lisible et habituel de mettre sur une classe les requêtes qui s'y rapportent. On notera d'ailleurs que la dernière de nos requête retournent un entier. Enfin, et afin de garantir l'unicité du nommage de nos requêtes au niveau de l'unité de persistance, nous avons préfixé le nom de ces requêtes par le nom de l'entité sur laquelle elles sont définies. Il ne s'agit pas d'une obligation, mais d'une bonne façon de faire.

3.4. Requêtes natives

Le JPQL ne permet pas de faire tout ce que l'on peut faire en SQL, pour cela il est possible de définir également des requêtes en SQL natif en JPA. On dispose pour cela de deux méthodes.

On peut utiliser la méthode createNativeQuery() de l' entity manager . Cette méthode prend une chaîne de caractères en paramètre : le code SQL natif que l'on veut exécuter.
On peut également définir des requêtes nommées natives. La syntaxe de déclaration est exactement la même que pour les requêtes JPQL nommées que l'on vient de voir, sauf que les annotations à utiliser sont @NamedNativeQueries et @NamedNativeQuery.

Cette possibilité offerte présente l'inconvénient d'attacher le code JPA à une base de données particulière. Cela dit, elle permet aussi de migrer des applications legacy plus simplement.

JPA & EJB

Retour au blog Java le soir

Cours & Tutoriaux