Discussion :

[mister bean]

Bonjour.

Je travaille sur un projet où il y a des articles qui peuvent être écrits par un ou plusieurs auteurs.

concretement j'ai une classe paper et une classe user.

dans Paper:

Code :

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

1
2
	@ManyToMany(mappedBy="papers")	
	private List<User> authors;

dans User:

Code :

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

1
2
3
4
5
6
7
	@ManyToMany(fetch=FetchType.EAGER)
	@JoinTable(name="t_authors_papers", 
			joinColumns=@JoinColumn(name="user_id", referencedColumnName="login"),
			inverseJoinColumns=
				@JoinColumn(name="paper_id", referencedColumnName="id")
	)
	private List<Paper> papers;

Le probleme, c'est que je ne sais absolument pas comment faire pour effacer pour effacer un article. Dans mes EJB stateless, quand je fais em.remove(aPaper), j'ai des exceptions à cause des contraintes d'integrité, et j'arrive pas à m'en dépétrer.

[denisjava]

supprimer un Paper peut se comprendre mais que veux tu faire les associations entre les personnes qui l'on écrit et le Paper concerné ?
Il faudrait peut etre commencer par supprimer les associations entre les User et le Paper...

idée en l'air:

soit p le paper a supprimer...

Code :

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

1
2
3
4
5
6
7
8
 
List auteurs = p.getAuthors();
for (Author a:auteurs) {
// Suppression de l'association, pas du paper !
// En gros, cela supprimer l'entrée dans la table d'association USER_PAPER
a.getPapers().remove(p); 
}
em.remove(p);

C'est la différence avec les EJB2, les associations ne sont plus managées !
le travail est à faire par le développeur (plus logique à mon avis)

enfin c'est à creuser... mais je pense que tu as un problème de ce style....

[mister bean]

effectivement c'est ce que j'avais pensé, mais le problème venait du getAuhors sur article, qui me renvoyait parfois des lazyInitialisationException, mais un bon FetchType.EAGER a réglé le problème

[denisjava]

L'abus de EAGER peut s'avérer très négatif d'un point de vue performance: peux tu me donner une trace des requêtes sql qui sont maintenant générées lors du chargement d'un Article ? Si par hasard tu venais à positionner l'association Auteur->Article comme Eager elle aussi alors tu remontes la base ! (je charge un article qui charge les auteurs qui chargent tous les articles de tous les auteurs précédent.....) cela peut aller loin (5 niveaux as défaut je crois)

Il vaut mieux préférer laisser Lazy et faire une requête HQL join fetch pour extraire les associations qui t'intéressent si tu le désires.

effectivement c'est ce que j'avais pensé, mais le problème venait du getAuhors sur article, qui me renvoyait parfois des lazyInitialisationException, mais un bon FetchType.EAGER a réglé le problème

[JeitEmgie]

effectivement c'est ce que j'avais pensé, mais le problème venait du getAuhors sur article, qui me renvoyait parfois des lazyInitialisationException, mais un bon FetchType.EAGER a réglé le problème

c'est une fausse solution :
une entité ne peut avoir qu'une seule relation EAGER…
le jour où vous aurez besoin d'une autre relation d'un même type à partir de cette entité, vous devrez trouver une vraie solution…

[loopx]

Bonjour, ben voilà, j'ai le meme problème.


En fait, j'ai aussi des lazyinitializationerror, et ce, à cause que mon bean n'est pas "attaché" quand je veux l'utiliser (récupérer une liste d'autre bean qui lui sont associé, lister le nombre de bean dans la liste ...).


C'est ici :
http://www.developpez.net/forums/sho...d.php?t=472496

[mister bean]

L'abus de EAGER peut s'avérer très négatif d'un point de vue performance: peux tu me donner une trace des requêtes sql qui sont maintenant générées lors du chargement d'un Article ? Si par hasard tu venais à positionner l'association Auteur->Article comme Eager elle aussi alors tu remontes la base ! (je charge un article qui charge les auteurs qui chargent tous les articles de tous les auteurs précédent.....) cela peut aller loin (5 niveaux as défaut je crois)

Il vaut mieux préférer laisser Lazy et faire une requête HQL join fetch pour extraire les associations qui t'intéressent si tu le désires.

Effectivement, le coup de la base qui remonte, faut y faire gaffe.

Je connais pas du tout les requetes HQL join-fetch.
Est-ce que cela me permettrait de resoudre mon problème sans utiliser le EAGER?
Sinon pour la trace des requetes SQL, je sais pas trop comment la recupérer, mais je veuxbien regarder si ca t'interesse.

[denisjava]

select a from Article a join fetch a.authors

Effectivement, le coup de la base qui remonte, faut y faire gaffe.

Je connais pas du tout les requetes HQL join-fetch.
Est-ce que cela me permettrait de resoudre mon problème sans utiliser le EAGER?
Sinon pour la trace des requetes SQL, je sais pas trop comment la recupérer, mais je veuxbien regarder si ca t'interesse.

[loopx]

j'ai réglé mon problème ...

On m'a aussi parlé de requette "fetch join" et truc machin ... la solution est pas aussi complexe je pense...


Enfin, avant ton erreur, tu doit faire un merge de ton entité (ca permettra de ratacher le bean entité au contexte de persistance).

Je te conseil de lire ceci (très très trop bon tuto):
http://pagesperso-orange.fr/emmanuel...eanEntite.html

Ensuite, j'aurais tendance à dire que cela se résous de la sorte:
(X = ton entité qui fait un lazy error ... ou celle qui contient un vecteur d'autre entité qui fait le lazy error ...)

Code :

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

X=entitymanager.merge(X);

maintenant, X est rattaché, le lazy ne devrait plus parraitre .. Pour le reste, aucune idée ... j'ai moi meme du mal à faire un manytomany correct

[denisjava]

Attention: écrire

Code :

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

X=entitymanager.merge(X);

est juste syntaxiquement juste mais trompeur...

Code :

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

Y=entitymanager.merge(X);

est plus adapté !

Ce qu'il se passe: X est détaché de son ctxt de persistence... mais n'en demeure pas moins référencé par un autre objet (une liste, une session http, ou autre...)
En faisant un merge, vous ne ré-attachez pas X à son contexte de persistence, vous récupérez une autre instance Y représentant les mêmes informations provenant de la base... Vous vous retrouvez donc avec deux objets représentant les même données dans la base: l'un attaché et l'autre détaché... Le problème c'est que l'objet X, initialement détaché reste détaché
et comme il est probable que vous utilisiez encore cet objet sans le vouloir et ben vous allez avoir des comportements que vous jugerez étranges...


L'avantage du join fetch est de permettre le chargement d'un graphe objet que l'on a besoin de manipuler en une seule fois... et vous évite notament le problème indiqué ci-dessus.

Un conseil: utilisez au maximum HQL afin de charger complètement le graphe objet sur lequel vous savez que vous allez travailler !
Perso, le merge il me fait fuir !

la solution est pas aussi complexe je pense...

La solution est complexe car le problème est complexe... Le mapping OR est complexe... rien n'est simple la dedans ! m'enfin, un join fetch n'a rien de complexe en fait...

j'ai réglé mon problème ...

On m'a aussi parlé de requette "fetch join" et truc machin ... la solution est pas aussi complexe je pense...


Enfin, avant ton erreur, tu doit faire un merge de ton entité (ca permettra de ratacher le bean entité au contexte de persistance).

Je te conseil de lire ceci (très très trop bon tuto):
http://pagesperso-orange.fr/emmanuel...eanEntite.html

Ensuite, j'aurais tendance à dire que cela se résous de la sorte:
(X = ton entité qui fait un lazy error ... ou celle qui contient un vecteur d'autre entité qui fait le lazy error ...)

Code :

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

X=entitymanager.merge(X);

maintenant, X est rattaché, le lazy ne devrait plus parraitre .. Pour le reste, aucune idée ... j'ai moi meme du mal à faire un manytomany correct