Les requêtes avec Hibernate 4

Hibernate 4 propose une syntaxe structurée qui permet d’exploiter la plupart des fonctionnalités du SQLLangage permettant de communiquer avec une base de données.. Cette syntaxe s’articule autour de quelques classes clés.

Les classes clés pour construire une requête

EntityManager

L’EntityManager vous donne accès à votre PersistenceUnit, c’est-à-dire à votre base de données. C’est donc à partir de lui que seront construits tous les objets suivants. La configuration de la PersistenceUnit fera l’objet d’un autre article.

CriteriaBuilder

Le CriteriaBuilder est généré par l’EntityManager. Il ne correspond à aucun élément d’une requête, mais c’est une boîte à outil pour construire des requêtes.

CriteriaQuery

Il s’agit de la requête à proprement parler. Elle est instanciée par le CriteriaBuilder. Notez qu’il s’agit d’une classe typée : son type doit être le type de retour de votre requête.

Root

C’est la clause FROM de votre requête SQL. C’est donc là encore un objet typé, à la différence que T doit impérativement être une @Entity, c’est-à-dire que la classe indiquée doit correspondre à une table dans votre schéma de base de données.

TypedQuery

Il s’agit d’un objet qui encapsule l’exécution de la requête. Son type doit donc impérativement être le même que celui de la CriteriaQuery(alors qu’il peut être différent de celui du Root).

La construction de la requête

Premier exemple

Prenons un exemple très simple : imaginons que j’ai une table utilisateur dans ma base de données, j’ai donc une @Entity Utilisateur. Je souhaite lister tous mes utilisateurs, je vais donc réaliser la requête « SELECT * FROM utilisateur; » avec Hibernate 4.

Ici, nous ne nous soucierons pas de comment obtenir l’EntityManager. Cela fera l’objet d’un autre article, nous admettrons que nous avons un objet EntityManager appelé entityManager. Le code pour réaliser notre requête est alors :

{{< highlight java >}} // Je cree une instance de CriteriaBuilder a partir de mon EntityManager CriteriaBuilder builder = entityManager.getCriteriaBuilder(); // Je cree une requete qui me retournera des objets Utilisateur CriteriaQuery< utilisateur> criteriaQuery = builder.createQuery(Utilisateur.class); // Je cree ma clause FROM sous forme d un objet Root Root< utilisateur> root = criteriaQuery.from(Utilisateur.class); // J indique la valeur de la clause SELECT criteriaQuery.select(root); // Je cree une TypedQuery pour l execution de ma requete TypedQuery< utilisateur> typedQuery = entityManager.createQuery(criteriaQuery); // J execute ma requete et je recupere le resultat dans une Collection List< utilisateur> result = typedQuery.getResultList();< /utilisateur>< /utilisateur>< /utilisateur>< /utilisateur>{{< /highlight >}}

Les 5 classes citées plus haut interviennent dans ce code. Quelques commentaires :

• La requête retourne le type Utilisateur : cela correspond bien à toutes les colonnes de la table utilisateur, c’est-à-dire « * FROM utilisateur » ;
• l’objet Root est obtenu à partir de la CriteriaQuery : en effet, il s’agit de la clause FROM de cette requête en particulier. Ce détail sera important lorsque vous aurez des sous-requêtes.
• la TypedQuery est, elle, obtenue à travers l’EntityManager : en effet, cet objet ne fait qu’exécuter la CriteriaQuery, or cette requête est bien exécutée sur le schéma représenté par l’EntityManager.

Deuxième exemple

Reprenons l’exemple précedent, mais cette fois nous ne voulons que le nom des utilisateurs. Notre requête SQL est donc « SELECT nom FROM utilisateur ».

Le code est le suivant :

{{< highlight java >}} CriteriaBuilder builder = entityManager.getCriteriaBuilder(); CriteriaQuery< string> criteriaQuery = builder.createQuery(String.class); Root< utilisateur> root = criteriaQuery.from(Utilisateur.class); criteriaQuery.select(root.get(Utilisateur_.nom)); TypedQuery< string> typedQuery = entityManager.createQuery(criteriaQuery); List< string> result = typedQuery.getResultList();< /string>< /string>< /utilisateur>< /string>{{< /highlight >}}

Il y a deux différences :

• j’indique en paramètre de la fonction select() le champ du metamodel de la classe Utilisateur qui correspond au champ que je veux récupérer ;
• le type de la CriteriaQuery et de la TypedQuery ne sont plus Utilisateur mais String puisque c’est bien un String que je souhaite obtenir.

Nous verrons dans d’autres articles comment récupérer plusieurs champs ou encore comment utiliser des fonctions telles que sum() ou count() dans la clause SELECT.

[wp-simple-survey-1]