La norme JPA prévoit de représenter les liens entre les tables via les annotations @OneToOne, @ManyToOne, @OneToMany et @ManyToMany. Par défaut, il faut définir si ces liens seront chargés à la demande ou obligatoirement. Mais peut-on faire autrement?

Présentation du modèle

Dans cet article, je vais prendre un modèle simple à deux tables: un utilisateur possède des bookmarks.

Entity User

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

import javax.persistence.*;
import java.io.Serializable;
import java.util.Date;
import java.util.Objects;

@Entity
@Table(name = "PUBLIC.PUBLIC.USERS")
@IdClass(UserPK.class)
public class User implements Serializable {
	@Id @Column(name="USERID") private String userid;

	public User() { }

	public String getUserid() { return userid; }
	public void setUserid(String userid) { this.userid = userid; }
}

Ici rien de spécial, on définit un utilisateur avec un identifiant.

Entity Bookmark

 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

import javax.persistence.*;
import java.io.Serializable;
import java.util.Date;
import java.util.Objects;

// Decrit un bookmark
@Entity
@Table(name = "PUBLIC.PUBLIC.BOOKMARKS")
@IdClass(BookmarkPK.class)
public class Bookmark implements Serializable {
	@Id @Column(name="BREF") private String ref; // Identifiant du bookmark
	@Column(name="TITLE") private String title; // titre du bookmark
	@Column(name="URI") private String uri; // URI du bookmark
	@Column(name="USERID") private String user; // identifiant de l'utilisateur proprietaire de ce bookmark


	public Bookmark() { }

	public String getRef() { return ref; }
	public void setRef(String ref) { this.ref = ref; }

	public String getTitle() { return title; }
	public void setTitle(String title) { this.title = title; }

	public String getUri() { return uri; }
	public void setUri(String uri) { this.uri = uri; }

	public String getUser() { return user; }
	public void setUser(String user) { this.user = user; }
}

Dans cette entité, on note que le bookmark est la propriété d’un utilisateur.

Repository BookmarkRepository

Pour mémoire, dans Apache Deltaspike, un repository est un service d’accès aux données.

Dans le repository BookmarkRepository, on a ajouté la méthode:

1
2

@Transactional(Transactional.TxType.REQUIRED)
public abstract List<Bookmark> findByUser(String user);

Cette méthode liste les bookmarks pour l’utilisateur indiqué (“nothing fancy here”).

Sans mapping

Lorsqu’on cherche la liste des bookmarks d’un utilisateur via la méthode findByUser, la requête générée est la suivante:

1

SELECT t0.BREF, t0.TITLE, t0.URI, t0.USERID FROM PUBLIC.BOOKMARKS t0 WHERE (t0.USERID = ?)

Comme aucun mapping n’est indiqué, la requête cherche uniquement dans la table des bookmarks, comme on pouvait s’en douter. Sauf qu’on ne pourra pas présenter d’informations sur l’utilisateur puisqu’on récupéré uniquement des bookmarks. On va alors ajouter un mapping (c’est à dire une entité liée) vers l’utilisateur.

Avec mapping

Deux possibilités s’offrent à nous: mapping avec chargement explicite (à la demande donc) ou mapping avec chargement forcé.

Mapping explicite “Lazy”

Dans la classe Bookmark, on ajoute le mapping vers le User grâce aux lignes suivantes:

1
2
3

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name="USERID", referencedColumnName="USERID")
private User owner;

La même recherche produit la même requête!

1

SELECT t0.BREF, t0.ADDED, t0.DELETED, t0.USERID, t0.TITLE, t0.UPDATED, t0.URI FROM PUBLIC.BOOKMARKS t0 WHERE (t0.USERID = ?)

C’est logique puisqu’on a configuré un chargement explicite du mapping (FetchType.LAZY).

On va donc modifier l’entity pour passer en chargement obligatoire.

Mapping forcé “Eager”

Ici on a remplacé “ @ManyToOne(fetch = FetchType.LAZY)” par “ @ManyToOne(fetch = FetchType.EAGER)”, provoquant le chargement forcé de l’entity liée.

La requête générée devient alors:

1

SELECT t0.BREF, t1.USERID, t0.TITLE, t0.URI, t0.USERID FROM PUBLIC.BOOKMARKS t0 LEFT OUTER JOIN PUBLIC.USERS t1 ON t0.USERID = t1.USERID WHERE (t0.USERID = ?)

La requête a la structure attendue pour un tel mapping.

Problème avec “Lazy” et “Eager”

La notion de chargement explicite ou forcée étant attachée au mapping lui-même, il est impossible de changer le fonctionnement pendant l’exécution. En effet, on n’a pas forcément toujours besoin d’un mapping annoté “Eager” mais il impossible d’éviter son chargement. A contrario, on a parfois besoin d’un mapping annoté “Lazy”: dans ce cas, on peut faire un “touch” pour provoquer le chargement mais JPA génère une requête supplémentaire au lieu de modifier la requête principale. Dans les deux cas (Lazy et Eager), la performance générale subit ces requêtes intempestives.

EntityGraph, le sauveur

La norme JPA 2.1 a ajoutée EntityGraph, qui permet justement de naviguer entre “Lazy” et “Eager”: on peut choisir pour chaque requête quels mappings on veut charger.

Mise en place

Modification de l’entité

Dans la classe Bookmark, on ajoute un EntityGraph nommé:

1
2
3

@IdClass(BookmarkPK.class)
@NamedEntityGraph(name = "Bookmark-owner", attributeNodes = { @NamedAttributeNode("owner") } )
public class Bookmark implements Serializable {

L’annotation @NamedEntityGraph comporte deux paramètres:

  • name: le nom de l’EntityGraph
  • attributeNodes: la liste des mappings à charger

Ensuite on repasse le mapping en FetchType.LAZY:

1
2
3

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name="USERID", referencedColumnName="USERID")
private User owner;

En procédant ainsi, on pourra charger l’entité Bookmark avec ou sans mapping User.

Modification du repository

Dans le repository BookmarkRepository, on modifie la méthode findByUser comme ceci:

1
2
3

@Transactional(Transactional.TxType.REQUIRED)
@EntityGraph(value = "Bookmark-owner")
public abstract List<Bookmark> findByUser(String user);

L’annotation @EntityGraph, via son paramètre value, fait le lien avec le profil définit dans l’entity par @NamedEntityGraph.

La requête générée devient alors celle attendue:

1

SELECT t0.BREF, t0.ADDED, t0.DELETED, t1.USERID, t1.EMAIL, t1.TOTP, t1.VALIDTO, t0.TITLE, t0.UPDATED, t0.URI, t0.USERID FROM PUBLIC.BOOKMARKS t0 LEFT OUTER JOIN PUBLIC.USERS t1 ON t0.USERID = t1.USERID WHERE (t0.USERID = ?)

Ensuite, on peut ajouter une méthode findByUserNM sans annoation @EntityGraph:

1
2

@Transactional(Transactional.TxType.REQUIRED)
public abstract List<Bookmark> findByUser(String user);

La requête générée est alors celle d’origine:

1

SELECT t0.BREF, t0.TITLE, t0.URI, t0.USERID FROM PUBLIC.BOOKMARKS t0 WHERE (t0.USERID = ?)

Conclusion

EntityGraph permet de gérer des profils de chargement des mappings et génère des requêtes optimisées. Cela permet d’améliorer assez facilement la performance générale des applications.