Spring Data JPA: ce qui est bon et ce qui est mauvais

Bébé est venu voir son père
Et a demandé au bébé
- Ce qui est bon
et ce qui est mauvais

Vladimir Mayakovsky

Cet article concerne Spring Data JPA, notamment dans le râteau sous-marin que j'ai rencontré en chemin, et bien sûr un peu sur les performances.

Les exemples décrits dans l'article peuvent être exécutés dans l'environnement de test, accessible par référence .

 public interface CrudRepository<T, ID> { T findOne(ID id); List<T> findAll(Iterable<ID> ids); } 

 public interface CrudRepository<T, ID> { Optional<T> findById(ID id); List<T> findAllById(Iterable<ID> ids); } 

Commençons donc.

sélectionnez t. * parmi t où t.id dans (...)

L'une des requêtes les plus courantes est une requête de la forme «sélectionner tous les enregistrements pour lesquels la clé appartient à l'ensemble transmis». Je suis sûr que presque tous ont écrit ou vu quelque chose comme

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") List<Long> ids); @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Set<Long> ids); 

Ceux-ci fonctionnent, les demandes appropriées, il n'y a pas de problème de capture ou de performance, mais il y a un petit inconvénient complètement invisible.

 public List<BankAccount> findByUserId(List<Long> userIds) { Set<Long> ids = new HashSet<>(userIds); return repository.findByUserIds(ids); } // public List<BankAccount> findByUserIds(Set<Long> userIds) { List<Long> ids = new ArrayList<>(userIds); return repository.findByUserIds(ids); } 

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Iterable<Long> ids); 

 public interface BankAccountRepositoryCustom { boolean anyMoneyAvailable(Collection<Long> accountIds); } public class BankAccountRepositoryImpl { @Override public boolean anyMoneyAvailable(Collection<Long> accountIds) { if (ids.isEmpty()) return false; //... } } 

Code supplémentaire: clés non dupliquées

Dans la suite de la dernière section, je voudrais attirer l'attention sur une idée fausse commune:

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Set<Long> ids); 

Autres manifestations de la même erreur:

 Set<Long> ids = new HashSet<>(notUniqueIds); List<BankAccount> accounts = repository.findByUserIds(ids); List<Long> ids = ts.stream().map(T::id).distinct().collect(toList()); List<BankAccount> accounts = repository.findByUserIds(ids); Set<Long> ids = ts.stream().map(T::id).collect(toSet()); List<BankAccount> accounts = repository.findByUserIds(ids); 

À première vue, rien d'inhabituel, non?

 select b.* from BankAccount b where b.user_id in (?, ?, ?, ?, ?, …) 

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Iterable<Long> ids); 

Samopis

Examinez attentivement ce code et trouvez ici trois défauts et une erreur possible:

 @Query("from User u where u.id in :ids") List<User> findAll(@Param("ids") Iterable<Long> ids); 

Harry potter et clé composée

Jetez un œil à deux exemples et choisissez celui que vous préférez:

Nombre de méthodes fois

 @Embeddable public class CompositeKey implements Serializable { Long key1; Long key2; } @Entity public class CompositeKeyEntity { @EmbeddedId CompositeKey key; } 

Méthode numéro deux

 @Embeddable public class CompositeKey implements Serializable { Long key1; Long key2; } @Entity @IdClass(value = CompositeKey.class) public class CompositeKeyEntity { @Id Long key1; @Id Long key2; } 

À première vue, il n'y a aucune différence. Essayez maintenant la première méthode et exécutez un test simple:

 //case for @EmbeddedId @Test public void findAll() { int size = entityWithCompositeKeyRepository.findAllById(compositeKeys).size(); assertEquals(size, 5); } 

Dans le journal des requêtes (vous le gardez, non?) Nous verrons ceci:

 select e.key1, e.key2 from CompositeKeyEntity e where e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? 

Maintenant, deuxième exemple

 //case for @Id @Id @Test public void _findAll() { int size = anotherEntityWithCompositeKeyRepository.findAllById(compositeKeys).size(); assertEquals(size, 5); } 

Le journal des requêtes est différent:

 select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? 

C'est toute la différence: dans le premier cas, nous recevons toujours 1 demande, dans le second - n demandes.
La raison de ce comportement réside dans SimpleJpaRepository::findAllById :

 // ... if (entityInfo.hasCompositeId()) { List<T> results = new ArrayList<>(); for (ID id : ids) { findById(id).ifPresent(results::add); } return results; } // ... 

La méthode qui vous convient le mieux est de déterminer en fonction de l'importance du nombre de demandes.

Extra CrudRepository :: enregistrer

Souvent, dans le code, il existe un tel contre-motif:

 @Transactional public BankAccount updateRate(Long id, BigDecimal rate) { BankAccount account = repo.findById(id).orElseThrow(NPE::new); account.setRate(rate); return repo.save(account); } 

Le lecteur est perplexe: où est l'anti-modèle? Ce code semble très logique: nous obtenons l'entité - mise à jour - sauvegarde. Tout est comme dans les meilleures maisons de Saint-Pétersbourg. J'ose dire que l'appel de CrudRepository::save est superflu ici.

Premièrement: la méthode updateRate transactionnelle, par conséquent, toutes les modifications dans l'entité gérée sont suivies par Hibernate et se transforment en demande lorsque Session::flush exécutée, ce qui se produit dans ce code à la fin de la méthode.

Deuxièmement, CrudRepository::save un coup d'œil à la méthode CrudRepository::save . Comme vous le savez, tous les référentiels sont basés sur SimpleJpaRepository . Voici l'implémentation de CrudRepository::save :

 @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else { return em.merge(entity); } } 

Il y a une subtilité dont tout le monde ne se souvient pas: Hibernate fonctionne à travers les événements. En d'autres termes, chaque action utilisateur génère un événement qui est mis en file d'attente et traité en tenant compte d'autres événements dans la même file d'attente. Dans ce cas, un appel à EntityManager::merge génère un MergeEvent , qui est traité par défaut dans la DefaultMergeEventListener::onMerge . Il contient une logique assez ramifiée mais simple pour chacun des états de l'argument entité. Dans notre cas, l'entité est obtenue à partir du référentiel à l'intérieur de la méthode transactionnelle et est à l'état PERSISTANT (c'est-à-dire essentiellement contrôlée par le framework):

 protected void entityIsPersistent(MergeEvent event, Map copyCache) { LOG.trace("Ignoring persistent instance"); Object entity = event.getEntity(); EventSource source = event.getSession(); EntityPersister persister = source.getEntityPersister(event.getEntityName(), entity); ((MergeContext)copyCache).put(entity, entity, true); this.cascadeOnMerge(source, persister, entity, copyCache); //<---- this.copyValues(persister, entity, entity, source, copyCache); //<---- event.setResult(entity); } 

Le diable est dans les détails, à savoir dans les méthodes DefaultMergeEventListener::cascadeOnMerge et DefaultMergeEventListener::copyValues . Écoutons le discours direct de Vlad Mikhalche , l'un des principaux développeurs d'Hibernate:

Dans l'appel de méthode copyValues, l'état hydraté est à nouveau copié, de sorte qu'un nouveau tableau est créé de manière redondante, ce qui gaspille les cycles CPU. Si l'entité a des associations enfants et que l'opération de fusion est également répercutée des entités parent aux entités enfant, la surcharge est encore plus importante car chaque entité enfant propage un événement MergeEvent et le cycle se poursuit.

En d'autres termes, on fait du travail que vous ne pouvez pas faire. En conséquence, notre code peut être simplifié tout en améliorant ses performances:

 @Transactional public BankAccount updateRate(Long id, BigDecimal rate) { BankAccount account = repo.findById(id).orElseThrow(NPE::new); account.setRate(rate); return account; } 

Bien sûr, il n'est pas pratique de garder cela à l'esprit lors du développement et de la relecture du code de quelqu'un d'autre, nous aimerions donc apporter des modifications au niveau de la structure filaire afin que la méthode JpaRepository::save perde ses propriétés nuisibles. Est-ce possible?

 // @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else { return em.merge(entity); } } // @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else if (!em.contains(entity)) { return em.merge(entity); } return entity; } 

Cependant, le lecteur averti a probablement déjà senti que quelque chose n'allait pas. En effet, ce changement ne cassera rien, mais seulement dans le cas simple où il n'y a pas d'entités enfants:

 @Entity public class BankAccount { @Id Long id; @Column BigDecimal rate = BigDecimal.ZERO; } 

Supposons maintenant que son propriétaire soit lié au compte:

 @Entity public class BankAccount { @Id Long id; @Column BigDecimal rate = BigDecimal.ZERO; @ManyToOne @JoinColumn(name = "user_id") User user; } 

Il existe une méthode qui vous permet de déconnecter l'utilisateur du compte et de transférer ce dernier au nouvel utilisateur:

 @Transactional public BankAccount changeUser(Long id, User newUser) { BankAccount account = repo.findById(id).orElseThrow(NPE::new); account.setUser(newUser); return repo.save(account); } 

Que va-t-il se passer maintenant? La vérification de em.contains(entity) renvoie true, ce qui signifie que em.merge(entity) ne sera pas appelé. Si la clé d'entité User est créée sur la base de la séquence (l'un des cas les plus courants), elle ne sera pas créée jusqu'à ce que la transaction soit terminée (ou que Session::flush appelée manuellement), c'est-à-dire que l'utilisateur sera à l'état DÉTACHÉ et son entité parent ( compte) - à l'état PERSISTANT. Dans certains cas, cela peut briser la logique d'application, ce qui s'est produit:

02/03/2018 DATAJPA-931 interrompt la fusion avec RepositoryItemWriter

À cet égard, la tâche Revert optimisations effectuées pour les entités existantes dans CrudRepository :: save a été créée et les modifications ont été apportées: Revert DATAJPA-931 .

Blind CrudRepository :: findById

Nous continuons à considérer le même modèle de données:

 @Entity public class User { @Id Long id; // ... } @Entity public class BankAccount { @Id Long id; @ManyToOne @JoinColumn(name = "user_id") User user; } 

L'application a une méthode qui crée un nouveau compte pour l'utilisateur spécifié:

 @Transactional public BankAccount newForUser(Long userId) { BankAccount account = new BankAccount(); userRepository.findById(userId).ifPresent(account::setUser); //<---- return accountRepository.save(account); } 

Avec la version 2. * l'anti-modèle indiqué par la flèche n'est pas si frappant - il est plus clairement visible sur les anciennes versions:

 @Transactional public BankAccount newForUser(Long userId) { BankAccount account = new BankAccount(); account.setUser(userRepository.findOne(userId)); //<---- return accountRepository.save(account); } 

 select u.id, u.name from user u where u.id = ? call next value for hibernate_sequence insert into bank_account (id, /*…*/ user_id) values (/*…*/) 

La première demande, nous obtenons l'utilisateur par clé. Ensuite, nous obtenons la clé du compte nouveau-né de la base de données et l'insérons dans le tableau. Et la seule chose que nous prenons à l'utilisateur est la clé, que nous avons déjà comme argument de méthode. D'un autre côté, BankAccount contient le champ "utilisateur" et nous ne pouvons pas le laisser vide (en tant que personnes décentes, nous définissons une restriction dans le schéma). Les développeurs expérimentés voient probablement déjà un moyen et manger un poisson et monter à cheval obtenir à la fois l'utilisateur et la demande de ne pas:

 @Transactional public BankAccount newForUser(Long userId) { BankAccount account = new BankAccount(); account.setUser(userRepository.getOne(userId)); //<---- return accountRepository.save(account); } 

JpaRepository::getOne retourne un wrapper sur la clé qui a le même type que "l'entité" vivante. Ce code ne donne que deux requêtes:

 call next value for hibernate_sequence insert into bank_account (id, /*…*/ user_id) values (/*…*/) 

Lorsqu'une entité en cours de création contient de nombreux champs avec une relation plusieurs à un / un à un, cette technique permet d'accélérer l'enregistrement et de réduire la charge sur la base de données.

Exécution de requêtes HQL

Il s'agit d'un sujet distinct et intéressant :). Le modèle de domaine est le même et il existe une telle demande:

 @Query("select count(ba) " + " from BankAccount ba " + " join ba.user user " + " where user.id = :id") long countUserAccounts(@Param("id") Long id); 

Considérez le HQL "pur":

 select count(ba) from BankAccount ba join ba.user user where user.id = :id 

Lors de son exécution, la requête SQL suivante sera créée:

 select count(ba.id) from bank_account ba inner join user u on ba.user_id = u.id where u.id = ? 

Le problème ici n'est pas immédiatement évident, même par une vie sage et des développeurs SQL bien compris: inner join par clé utilisateur exclura les comptes avec user_id manquant de l'échantillon (et dans le bon sens, l'insertion de ceux-ci devrait être interdite au niveau du schéma), ce qui signifie qu'il n'est pas user_id de rejoindre la table user du tout besoin de. La demande peut être simplifiée (et accélérée):

 select count(ba.id) from bank_account ba where ba.user_id = ? 

Il existe un moyen d'obtenir facilement ce comportement en c à l'aide de HQL:

 @Query("select count(ba) " + " from BankAccount ba " + " where ba.user.id = :id") long countUserAccounts(@Param("id") Long id); 

Cette méthode crée une requête «allégée».

Résumé de la requête et de la méthode

L'une des principales caractéristiques de Spring Data est la possibilité de créer une requête à partir du nom de la méthode, ce qui est très pratique, en particulier en combinaison avec le module complémentaire intelligent d'IntelliJ IDEA. La requête décrite dans l'exemple précédent peut être facilement réécrite:

 // @Query("select count(ba) " + " from BankAccount ba " + " where ba.user.id = :id") long countUserAccounts(@Param("id") Long id); // long countByUserAccount_Id(Long id); 

Il semble être plus simple, plus court et plus lisible, et surtout - vous n'avez pas besoin de regarder la demande elle-même. J'ai lu le nom de la méthode - et c'est déjà clair ce qu'elle choisit et comment. Mais le diable est ici dans les détails. Nous avons déjà vu la dernière requête pour la méthode marquée avec @Query . Que se passera-t-il dans le deuxième cas?

 select count(ba.id) from bank_account ba left outer join // <--- !!!!!!! user u on ba.user_id = u.id where u.id = ? 

"Que diable!?" - s'exclamera le développeur. Après tout, nous avons déjà vu que violoniste join pas nécessaire.

La raison est prosaïque:

• JPADATAJPA-729 OUTER JOIN inutiles sont générés pour compter une seule table
• DATAJPA-1238 Inutile LEFT OUTER JOIN inutile quand un WHERE aurait pu être utilisé

Si vous n'avez pas encore mis à niveau vers les versions corrigées et que rejoindre la table ralentit la demande ici et maintenant, alors ne désespérez pas: il y a deux façons de soulager la douleur:

• une bonne façon est d'ajouter optional = false (si le circuit le permet):

  
  

   @Entity public class BankAccount { @Id Long id; @ManyToOne @JoinColumn(name = "user_id", optional = false) User user; } 

  
  

• La manière la plus simple consiste à ajouter une colonne du même type que la clé d'entité User et à l'utiliser dans des requêtes au lieu du champ user :

  
  

   @Entity public class BankAccount { @Id Long id; @ManyToOne @JoinColumn(name = "user_id") User user; @Column(name = "user_id", insertable = false, updatable = false) Long userId; } 

  
  

  Maintenant, la méthode request-from-method sera plus agréable:

  
  

   long countByUserId(Long id); 

  
  

  donne

  
  

   select count(ba.id) from bank_account ba where ba.user_id = ? 

  
  

  qu'avons-nous réalisé.

  
  

Limite d'échantillonnage

Pour nos besoins, nous devons limiter la sélection (par exemple, nous voulons renvoyer Optional partir de la méthode *RepositoryCustom ):

 select ba.* from bank_account ba order by ba.rate limit ? 

Maintenant Java:

 @Override public Optional<BankAccount> findWithHighestRate() { String query = "select b from BankAccount b order by b.rate"; BankAccount account = em .createQuery(query, BankAccount.class) .setFirstResult(0) .setMaxResults(1) .getSingleResult(); return Optional.ofNullable(bankAccount); } 

Le code spécifié a une caractéristique désagréable: dans le cas où la demande retourne une sélection vide, une exception sera levée

 Caused by: javax.persistence.NoResultException: No entity found for query 

Dans les projets que j'ai vus, cela a été résolu de deux manières principales:

• try-catch avec des variantes de la Optonal.empty() exception et le retour d' Optonal.empty() à des méthodes plus avancées, comme passer un lambda avec une requête à une méthode utilitaire
• aspect dans lequel les méthodes de référentiel sont renvoyées renvoyées Optional

Et très rarement, j'ai vu la bonne solution:

 @Override public Optional<BankAccount> findWithHighestRate() { String query = "select b from BankAccount b order by b.rate"; return em.unwrap(Session.class) .createQuery(query, BankAccount.class) .setFirstResult(0) .setMaxResults(1) .uniqueResultOptional(); } 

EntityManager fait partie de la norme JPA, tandis que Session appartient à Hibernate et est à mon humble avis un outil plus avancé, qui est souvent oublié.

[Parfois] amélioration néfaste

Lorsque vous avez besoin d'obtenir un petit champ à partir d'une entité "épaisse", nous faisons ceci:

 @Query("select a.available from BankAccount a where a.id = :id") boolean findIfAvailable(@Param("id") Long id); 

La demande vous permet d'obtenir un champ de type boolean sans charger l'entité entière (avec l'ajout d'un cache de premier niveau, la vérification des modifications à la fin de la session et d'autres dépenses). Parfois, cela non seulement n'améliore pas les performances, mais vice versa - il crée des requêtes inutiles à partir de zéro. Imaginez un code qui effectue quelques vérifications:

 @Override @Transactional public boolean checkAccount(Long id) { BankAccount acc = repository.findById(id).orElseThow(NPE::new); // ... return repository.findIfAvailable(id); } 

Ce code fait au moins 2 requêtes, bien que la seconde puisse être évitée:

 @Override @Transactional public boolean checkAccount(Long id) { BankAccount acc = repository.findById(id).orElseThow(NPE::new); // ... return repository.findById(id) //    .map(BankAccount::isAvailable) .orElseThrow(IllegalStateException::new); } 

La conclusion est simple: ne négligez pas le cache du premier niveau, dans le cadre d'une transaction, seul le premier JpaRepository::findById fait référence à la base de données, JpaRepository::findById cache du premier niveau est toujours JpaRepository::findById et lié à une session, qui est généralement liée à la transaction en cours.

Tests avec lesquels jouer (le lien vers le référentiel est donné au début de l'article):

• test d'interface étroite: InterfaceNarrowingTest
• tester un exemple avec une clé composite: EntityWithCompositeKeyRepositoryTest
• tester l'excès de CrudRepository::save : ModifierTest.java
• test aveugle CrudRepository::findById : ChildServiceImplTest
• test de left join inutile: BankAccountControlRepositoryTest

Le coût d'un appel supplémentaire à CrudRepository::save peut être calculé à l'aide de RedundantSaveBenchmark . Il est lancé à l'aide de la classe BenchmarkRunner .