Améliorer la performance d'une requête de sélection

Version imprimable

09/02/2010, 18h07
saveriu

Améliorer la performance d'une requête de sélection

Bonjour,

Je voudrais faire une sélection de tous les utilisateurs de ma base. Ces entités Utilisateur ont beaucoup d'attributs et de relations et je n'en ai aucune en EAGER mode. Mais je constate que tout de même, cela met beaucoup de temps à récupérer les données (base externe). Je voudrais voir s'il était possible d'avoir uniquement quelques attributs de classe chargés (id, nom, prénom) mais que la requête me retourne bien des instances Utilisateur. Les attributs non chargés le seront en LAZY mode si besoin est.

Merci
09/02/2010, 21h25
Beruboy

Tu fais ta sélection en JDBC? En Hibernate?

Peut-être que je n'ai pas compris la question, mais un simple

Citation:

SELECT id,nom,prenom FROM ...
10/02/2010, 11h11
JeReMsS69

J'ai également le même soucis !
Un nombre énorme de requête !
N'est-il pas possible de générer 1 seule requête complète au lieu de faire un select pour chaque entité?
10/02/2010, 11h23
OButterlin

Il faudrait être plus précis dans la demande.
Merci de montrer également le mapping concerné...
10/02/2010, 16h01
saveriu

Excusez mon retard, je pensais avoir activer la notification. Je suis sous JPA et implémentation Toplink. Les requêtes sont donc en JPQL. Il n'y a donc pas vraiment de mapping mais un ensemble d'entités annotées. Je suppose que vous montrer la classe Utilisateur est inutile, à moins que vous le vouliez vraiment??
@Beruboy: La requête "select u.id, u.nom, u.prenom from Utilisateur u" en JPQL retourne t-elle bien des instances d'Utilisateur quand on fait le getResultList()?
10/02/2010, 16h53
OButterlin

Il serait important de voir la/les classe(s) annotée(s).

Ensuite, si la question est : "comment optimiser une requête sur une entité référençant en lazy loading d'autres entités"
alors, oui, il y a moyen de "diriger" les sous-requêtes via l'instruction " join fetch " dans un Query.

Voici mes classes (j'ai enlevé quelques attributs et méthodes):

L'entité Personne:

Code:

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
 
@Entity
@Inheritance(strategy=InheritanceType.JOINED)
public abstract class Personne implements Serializable, java.lang.Comparable  {
 
 
    @OneToMany(mappedBy = "personne", cascade=CascadeType.ALL)
    private List<ElementSalaire> elementsSalaire;
    @OneToMany(mappedBy = "executeur", cascade=CascadeType.ALL)
    private List<Action> actionsExecution;
    @OneToMany(mappedBy = "emetteur", cascade=CascadeType.ALL)
    private List<Action> actionsEmission;
    @OneToMany(mappedBy = "recepteur", cascade=CascadeType.ALL)
    private List<Action> actionsReception;
    @OneToMany(mappedBy = "evalue", cascade=CascadeType.ALL)
    private List<NotationPersonne> notationsPersonne;
    private static long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
 
    private String nom="";
    private String prenom="";
 
    @OneToOne(cascade = CascadeType.ALL)
    private Adresse adresse;
 
    @Temporal(javax.persistence.TemporalType.DATE)
    private java.util.Date dateNaissance;
 
    private String tel="";
    private String portable="";
    private String fax="";
    private String mail="";
    private String lieuNaissance="";
    private String id2="";
    private String titre="";
    private String nationalite="";
 
 
    public Personne() {
        setAdresse(new Adresse());
        dateNaissance =new java.util.Date();
        notationsPersonne = new Vector<NotationPersonne>();
        elementsSalaire = new Vector<ElementSalaire>();
        actionsEmission = new Vector<Action>();
        actionsExecution = new Vector<Action>();
        actionsReception = new Vector<Action>();
        candidatures = new Vector<Candidature>();
 
    }
 
    public int compareTo(Object other) {
      return this.toString().compareTo(other.toString());
   }
 
 
    public Personne(String titre, String nom, String prenom, Adresse adresse) {
        this();
        setTitre(titre);
        setNom(nom);
        setPrenom(prenom);
        setAdresse(adresse);
    }
 
 
}

L'entité Utilisateur:

Code:

1
2
3
4
5
6
7
8
9
10
11
 
@Entity
public class Utilisateur extends Personne implements Serializable {
 
    @OneToMany(mappedBy = "evaluateur")
    private List<NotationPersonne> notationsDonnees;
 
    @OneToMany(mappedBy = "utilisateur", cascade = CascadeType.ALL)
    private List<LienUtilisateurAgence> liensUtilisateurAgence;
 
}

Je voudrais faire une sélection de tous les utilisateur:

Code:

1
2
3
4
5
 
public List<Utilisateur> getAllUtilisateur() {
        Query query = getEm().createQuery("SELECT u FROM Utilisateur u order by u.nom asc, u.prenom asc");
        return query.getResultList();
    }

10/02/2010, 17h13
OButterlin

Ben, c'est bien ce que fait ta requête là 8O
Il y a un problème ?
10/02/2010, 17h18
saveriu

Le problème est que cela met beaucoup de temps à charger les utilisateurs (l'implémentation de JPA est sur un client distant par rapport à la base SQL).
En gros je veux juste savoir si la requête: "select u.id, u.nom, u.prenom from Utilisateur u" me retourne bien des instances d'Utilisateur avec uniquement les nom, prénom et id chargés.
10/02/2010, 17h31
OButterlin

Il me semble que dans ce cas, tu vas récupérer une liste de tableaux d'objets, pas une liste d'objets Utilisateur avec uniquement tes 3 champs.
10/02/2010, 17h39
saveriu

C'est ce qui me semblait... Alors je pense qu'il n'y a pas de solution à ce problème.
J'ai aussi remarqué que JPA utilisait les constructeurs par défaut des entités ( this() ) et que, si je surcharge le constructeur par défaut, il va le lancer pour chaque entités pendant leur chargement.
Si on remarque bien, le constructeur de Personne et Utilisateur sont redéfinis et créent des instances de ArrayList, Adresse, etc. donc cela peut influer sur les performances.
A voir...
10/02/2010, 17h54
Heimdal

As-tu testé avec une NamedQuery?
10/02/2010, 18h15
saveriu

Ah? C'est une idée intéressante... Je les utilise pour les requêtes complexes mais c'est pas bête d'essayer...
11/02/2010, 14h00
OButterlin

Ça ne changera pas le fait que tu récupéreras une liste<Object[]>...
Maintenant, tu peux passer par un query natif également, ça évitera de traverser 36 couches, mais tu auras tout de même un tableau d'objets en retour...
L'un dans l'autre, c'est très proche... mais tu as un contrôle plus fin.