getHibernateTemplate.update ne marche pas

Version imprimable

Hello,

Je rencontre des difficultés à mettre à jour un élément existant à l'aide de

getHibernateTemplate.update (affaire) rien n est mise à jour

j ai donc codé ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public void update(Affaire affaire) throws Exception { LOG.debug("UPDATE AFFAIRE FROM DAO : " + affaire.getNoAffaire()); try{ Commune c = affaire.getCommunes().iterator().next(); delete(findByNoAffaire(affaire.getNoAffaire())); affaire.addCommune(c); LOG.debug("SAVE AFFAIRE WITH THIS COMMUNE AFTER DELETE " + affaire.getCommunes().iterator().next().getLibelleFr()); Object o = getHibernateTemplate().save(affaire); if (o == null) { LOG.error("ERROR SAVING AFFAIRE INSIDE UPDATE"); } }catch (Exception ex) { LOG.error("error while updating affaire" + ex.getMessage()); throw ex; } }
mais la encore il arrive parfois (1 fois sur 10) que l affaire n est pas supprimé dans la base

de quoi cela peut il provenir ?

05/02/2009, 09h38
ohanny

Pour analyser, il est préférable d'avoir la trace des requêtes SQL exécutées. Mais déjà, il y a qq ch de suspect dans le code quant à l'objet affaire. Voici le cycle de vie :

1. "affaire" est passé en paramètre, probablement instance détachée => mettons que son id vaut 3
2. delete(findByNoAffaire(affaire.getNoAffaire())) => suppression de l'affaire n°3 en base (du moins, l'id 3 est marqué pour être supprimé en base, le sql n'est pas généré tout de suite). A ce stade, l'objet affaire ci-dessus n'est pas impacté puisqu'il est détaché => son id en mémoire java reste à 3
3. save(affaire) => affaire est réattaché à la session, avec un id non null, mais cet id est supposé être supprimé de la base => pas logique
05/02/2009, 10h22
*alexandre*

Hello,

J'ai également testé une *version* ou :

1) Je créer une transaction
2) evict l'objet affaire de la session
3) load affaire avec un session.get()
4) delete l'objet affaire
5) save l objet affaire
6) commit la transaction

Mais la je m'étais retrouvé face à l'exception suivante :

org.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session:
05/02/2009, 17h58
ohanny

as-tu essayé un flush entre le delete et le save ?

Hello,

Si je met un flush, j'obtiens l'exception suivante :

Found two representations of same collection within affaireLiees

En cherchant un peu j ai trouvé ceci :

http://forum.hibernate.org/viewtopic.php?p=2231400

mais ca ne sauvegarde pas les relations ... le code utilisé :
Code:

1 2 3 4 5 6 7 8 9 10 11 session.delete(affaire); session.flush(); session.clear(); session.evict(affaire); affaire.setAffairesLiees(new HashSet<Affaire>(affaire.getAffairesLiees())); affaire.setAuteurs(new HashSet<AuteurPlans>(affaire.getAuteurs())); affaire.setRequerants(new HashSet<Requerant>(affaire.getRequerants())); affaire.setCommunes(new HashSet<Commune>(affaire.getCommunes())); affaire.setParcelles(new HashSet<Localisation>(affaire.getParcelles()));
Je me suis tourné donc à nouveau vers le session.update :
Code:

1 2 3 4 5 6 7 Session session = getSession(); session.getSessionFactory().openSession(); Transaction tx = session.beginTransaction(); session.update(affaire); tx.commit(); session.close();
mais cette fois lorsque je sauvegarde cela me créer deux affaires

06/02/2009, 10h52
ohanny

J'ai déjà rencontré un pb de double insertion : le pb venait d'une relation bi-directionnelle (one-to-many) dont les objets placés dans la collection ne redéfinissaient pas les méthodes equals() et hashCode()

J'ai bien vérifié mes entités et le problème ne vient pas de là.

ou alors peut être que je n'utilise pas les bonnes méthodes

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
	/*
	 * (non-Javadoc)
	 * 
	 * @see java.lang.Object#equals(java.lang.Object)
	 */
	@Override
	public boolean equals(Object obj) {
		return EqualsBuilder.reflectionEquals(this, obj);
	}
 
	/*
	 * (non-Javadoc)
	 * 
	 * @see java.lang.Object#equals(java.lang.Object)
	 */
	@Override
	public int hashCode() {
		return HashCodeBuilder.reflectionHashCode(this);
	}

06/02/2009, 13h40
ohanny

ok, alors il faut s'assurer que le pb ne vient pas des liens => si c'est possible, ce serait bien de faire une essai d'update en désactivant le mapping des liens (affairesLiees, auteurs...)
06/02/2009, 13h43
ohanny

je viens aussi de me souvenir d'un autre pb du genre que j'ai rencontré : je ne sais pas pourquoi, mais cela venait de l'HibernateTemplate de spring. Pour résoudre, j'avais modifié le code de façon à ne pas travailler avec l'HibernateTemplate, mais directement avec la session Hibernate que tu peux récupérer depuis HibernateDaoSupport...on ne sais jamais ;)
06/02/2009, 14h05
*alexandre*

c'est justement ce que je suis entrain de faire :mrgreen:
06/02/2009, 14h06
ohanny

ok, bonne chance !
06/02/2009, 14h20
*alexandre*

Le problème de duplicate semble avoir disparu.
06/02/2009, 14h22
ohanny

pour info, quelle était la solution ?
06/02/2009, 14h27
*alexandre*

J'effectue un delete à partir de mon findAffaireByNumero et ensuite un save ...
22/05/2009, 10h35
wajdopovitch

Citation:

Envoyé par *alexandre*

J'effectue un delete à partir de mon findAffaireByNumero et ensuite un save ...

Je suis tombé dans le même problème , et cette solution n'est pas efficace ,
t'aurais pus utiliser une requête pour la mise à jour de l'objet
car dans mon cas , j'ai bcp de relations avec la classe principale
et si je fais un delete je perd tout :(
je suis à la recherche d'une autre solution