Discussion :

[tchize_]

comme je l'ai dit, tu va récupérer un List<Object[]> avec çà, pas un List<Personne>, ca fait toute la différence.

Je vois pas en quoi ma proposition bafouerais le principe MVC, au contraire, avec ton système, si t'as une donnée à afficher en plus, t'es obligé de passer par le code pour changer ta query hibernate et inclure la donnée manquante. Donc tu as bien pollution de ton modèle par les spécificités de la vue.
bon tu peux toujours rajouter une couche dans ton bean qui prend une List<Personne> et te filtre toutes les données, de toutes facons, c'est à toi de voir.

[DeathMaker]

comme je l'ai dit, tu va récupérer un List<Object[]> avec çà, pas un List<Personne>, ca fait toute la différence.

Oui... J'ai déjà été confronté à ce problème.
Ce que tu peux faire, c'est boucler sur les résultats, et de peupler dynamiquement un Set.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Set<Personne> personnes = new HashSet<Personne>();
for(Object[] o : myResult){
    personnes.add(o[0]);
}
return personnes;

[pontus21]

Là, je vous ai donné un sous exemple, mais je vais avoir à construire une requête avec 5 niveaux.
Donc peupler à chaque fois une liste, ça va être lourd ...

Ma requête hibernate me renvoit ce que je veux.
Seulement si la seconde requête renvoit la même personne (soit, le niveau le plus haut), cet objet n'est pas reconstruit puisqu'il est en mémoire.

Y a-t-il un moyen de forcer le rechargement de l'objet ?

[tchize_]

non, puisque, de fait, l'objet est le même! Tu peux éventuellement faire un session.refresh(objet), mais ca ne sert que pour les cas où la base de donnée à changé depuis la dernière fois, en dehors de la session.

Hibernate fait normalement ceci:


- création d'une requete SQL à partir de ton HQL
- exécution de cette requete
- récupération des données et peuplement, éventuellement partiel, de la structure objet a partir de ces donnée (tout dépend des stratégies utilisées, la requete peut avoir retourné des objet complet ou juste des ids, mais ca change rien au code appelant)
- éventuellement, nouvelles requetes HQL pour terminer de peupler tes objet pour les propriétés / relations où le lazy=false
- Renvoi à l'appelant de la liste "Personne"

L'appelant explorer une propriété ou relation d'un des objet Hibernate
- le proxy hibernate vérifie que la propriété / relation a été initialisé. Si pas, il effectue les requetes SQL nécessaire que pour remplir l'objet. Si la session est fermée, une lazyloadingexception est lancée.
- le proxy renvoie la valeur demandée.


La première partie ce fait lors de ta requete, la deuxième, dans ton cas, au sein de ton JSP


Donc, pour rendre les chose claires. Si la requete 1 doit renvoyer les personnes X et Y ET que la requete 2 doit aussi renvoyer les personnes X et Y, alors l'affichage dans ton jsp de ces deux listes de personne devrait être identique.

[pontus21]

Merci pour ces explications, c'est effectivement ce qu'il se passe, je pense ...
En tous cas, ça y ressemble beaucoup !

Est-ce que sans passer par Hibernate, je pourrais obtenir plus facilement ce que je souhaite ?

[pontus21]

Pour le moment, un "session.clear();" me permet de vider la session et donc hibernate va reconstruire à chaque l'objet selon ma recherche.
Ca a au moins le mérite de me donner ce que je veux.

Sinon, petite question subsidiaire : c'est possible d'utiliser plusieurs utilisateurs de BDD avec Hibernate ?

[tchize_]

non, mais tu peux avoir plusieurs sessions active en meme temps.

PS: j'ai aps compris en quoi recharger depuis la db donne ce que tu veux, puisque normalement a moins que t'aie un mapping raté, ce doit donner le même résultat tes requetes HQL, qu'il y aie ou non des données dans la session! Sinon t'as une méchante inconsistance quelque part

[pontus21]

Pourquoi je recharge depuis la DB ?

Tout simplement pour obtenir l' "arborescence" souhaitée.

Ainsi, avec ma requête et le paramètre idAnim = 1, il renvoie la personne 111 avec l'événement 11 qui a pour anim 1

Ensuite, si je fais une requête avec idAnim = 2, il renvoie la personne 111. Et comme il l'a déjà chargée, il ne va pas faire d'autres requêtes dans la base pour continuer à construire l'objet. Il me retourne directement l'objet qu'il a stocké précédemment.

Or, j'aimerais qu'il me renvoie la personne 111 avec l'événement 22 qui a pour anim 2 ...


Donc le vidage de ma session me permet d'obtenir ce que je veux !

[tchize_]

comem déjà dit, il doit te renvoyer dans les deux cas la personne 111 avec deux évènements: 11 et 22 à moins que t'ai raté ton mapping Y a pas re raison que personne.evenements ne contienent qu'un seul élément quand la DB contient deux valeurs Si t'es content tant mieux, mais je signale juste que c'est pas le comportement normal d'hibernate et que tu risque de revenir plus tard avec ce problème.

[pontus21]

Y a pas re raison que personne.evenements ne contienent qu'un seul élément quand la DB contient deux valeurs

Suivant ma jointure, y'a une raison !
Enfin, j'ai trouvé une solution, c'est le principal !

[tchize_]

si tu parle de la jointure HQL, justement non, le contenu de personnes.evenements doit être indépendant de cette jointure (c'est quand meme un des garantie que donne hibernate). Si tu parle de ton modèle de base de donnée, je m'inquiéterait d'avoir une relation qui change comme çà au fil du temps sans que la db ne change


La j'avoue, je suis un peu largué sur le comportement de ta db et ton modèle

[pontus21]

C'est pas la relation qui change !

Mais avec une jointure et un filtre sur cette jointure, c'est quand même normal que ma requête ne me retourne pas autant d'enregistrement que sans filtre et avec une jointure externe !

[tchize_]

alors soit on parle pas la meme langue soit j'ai vraimentdu mal a me faire comprendre
avec hibernante, peut importe la requete que tu a utilisé pour récupérer un objet "Personne", quand tu fera personne.getEvenements() (ce que fait ton jsp via les boucle for) tu aura toujours la même liste d'évènement. autrement dit, que je fasse:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT p  From Personne AS p  left join fetch p.evenements AS e  left join fetch e.animateurs a WHERE a.idAnim = '11'

qui te retourne la Personne 111

ou que tu fasse

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT p  From Personne AS p where p.id=111

qui te retourne aussi la Personne 111

ou encore

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT p  From Personne AS p  left join fetch p.evenements AS e  left join fetch e.animateurs a WHERE a.idAnim = '22'

qui te retourne aussi la personne 111

quand tu fera personne.getEvenements() tu aura toujours la même liste d'évènements, quel que soit le nombre d'évènements retournés par la requete HQL initiale puisque, c'est là la magie d'hibernate, tes collections sont indépendante de la requete initiale et il va remplir correctement avec les selects nécessaire la List<Evenement> (ou le Set ou le Bag peu importe ce que tu as choisi) au moment opportun, pour que justement cette liste soit complète et reflète la base de donnée, non ta requete HQL initiale.

Et si c'est pas le cas, c'est que t'as fait une bidouille quelque part dont je suis pas au courant, ou que t'as un sérieux problème avec ton mapping quelque part.

[pontus21]

Peut-être ai-je un problème.

Toujours est-il que ça me rend ce que je veux, alors que je galèrais pour trouver ...

Je vais donc laisser comme ça, puisqu'apparemment, il n'y pas de moyen "plus propre" pour faire ce que je voudrais avec Hibernate.

Sinon, si j'ai un peu de temps plus tard, je verrai pour faire directement en SQL.

[pontus21]

Bon, effectivement, vous aviez raison ...

Je reviens vers vous car les performances de ma partie Hibernate plombent littéralement mon application ...
Etant donné qu'à chaque fois, Hibernate requête dans la base, ça met un temps fou, car j'ai des millions d'enregistrements en base.

Il faut donc que je trouve un moyen plus clair pour faire mes restrictions comme cela, Hibernate mettra du temps à charger la base complète mais j'aurai des temps de réponse beaucoup plus intéressants (c'est ce que j'espère).

Je vous écoute donc ...