Recherche…


Ne pas utiliser le type de récupération EAGER

Hibernate peut utiliser deux types d'extraction lors de la cartographie de la relation entre deux entités: EAGER et LAZY .

En général, le type de récupération EAGER n'est pas une bonne idée, car il indique à JPA de toujours récupérer les données, même si ces données ne sont pas nécessaires.

Par exemple, si vous avez une entité Person et la relation avec Address comme ceci:

@Entity
public class Person {

  @OneToMany(mappedBy="address", fetch=FetchType.EAGER)
  private List<Address> addresses;

}

Chaque fois que vous interrogez une Person , la liste de l' Address de cette Person sera également retournée.

Donc, au lieu de mapper votre entité avec:

@ManyToMany(mappedBy="address", fetch=FetchType.EAGER)

Utilisation:

@ManyToMany(mappedBy="address", fetch=FetchType.LAZY)

Une autre chose à faire attention est les relations @OneToOne et @ManyToOne . Les deux sont EAGER par défaut . Donc, si vous êtes préoccupé par les performances de votre application, vous devez définir la récupération pour ce type de relation:

@ManyToOne(fetch=FetchType.LAZY)

Et:

@OneToOne(fetch=FetchType.LAZY)

Utiliser la composition au lieu de l'héritage

Hibernate a des stratégies d'héritage. Le type d'héritage JOINED effectue une jointure entre l'entité enfant et l'entité parent.

Le problème avec cette approche est que Hibernate apporte toujours les données de toutes les tables impliquées dans l'héritage.

Par exemple, si vous avez les entités Bicycle et MountainBike utilisant le type d'héritage JOINED :

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public abstract class Bicycle {

}

Et:

@Entity
@Inheritance(strategy = InheritanceType.JOINED)
public class MountainBike extends Bicycle {

}

Toute requête JPQL qui frappe MountainBike amènera les données Bicycle , créant une requête SQL telle que:

select mb.*, b.* from MountainBike mb JOIN Bicycle b ON b.id = mb.id WHERE ...

Si vous avez un autre parent pour Bicycle (comme Transport , par exemple), cette requête ci-dessus apportera également les données de ce parent, effectuant une JOIN supplémentaire.

Comme vous pouvez le voir, il s’agit également d’une sorte de cartographie EAGER . Vous n'avez pas le choix d'apporter uniquement les données de la table MountainBike aide de cette stratégie d'héritage.

Le meilleur pour la performance est la composition plutôt que l'héritage.

Pour ce faire, vous pouvez mapper l'entité MountainBike pour avoir un bicycle terrain:

@Entity
public class MountainBike {

    @OneToOne(fetchType = FetchType.LAZY)
    private Bicycle bicycle;

}

Et le Bicycle :

@Entity
public class Bicycle {

}

Chaque requête apportera désormais uniquement les données MountainBike par défaut.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow