Données qui deviennent invisibles dans la transaction

Version imprimable

22/04/2013, 11h56
devyan

Données qui deviennent invisibles dans la transaction

Bonjour,

L'intitulé étant plutôt étrange je vais essayer d'être clair dans mes explications...

J'ai un problème récurrent lorsque je réalise mes Tests junit avec la visibilité des données entre les requêtes HQL et les requêtes SQL au sein d'une même transaction.

J'ai un enchainement de requêtes HQL et SQL qui fonctionne lors de la création :
1/ création des objets et sous objets
2/ sauvegarde (via hibernate)
3/ lecture (à ce niveau hibernate via find et SQL via select me renvoient bien les données attendues)
4/ ajout d'autres objets à partir des données obtenues en "3"
5/ contrôle (ici tout est ok)

6/ modification des objets/sous-objets
7/ sauvegarde
8/ purge des données ajoutées en "4"
9/ lecture (à ce niveau SQL via select ne me renvoie pas les données)
10/ ajout d'autres objets à partir des données obtenues en "9"
11/ contrôle (ici tout est ko = vide puisque "9" n'a rien trouvé)

La sauvegarde est la même fonction dans les 2 cas.
Tout ce passe dans la même transaction (je fais un rollback en fin de test)

Pour info, l'étape "3"/"9" est un SELECT sur des tables différentes de la table dans laquelle les données "4"/"10" sont ajoutées.
Cependant, la requête Oracle est assez complexe et je n'ai pas pu la passer en HQL (elle contient un SELECT FROM ALL_OBJECTS afin de générer une liste de dates utilisée comme jointure afin de générer mes données.

Mes multiples recherches sur le net m'amènent à penser que le pb serait lié au cache de premier niveau d'hibernate...

Merci d'avance,

devyan.
22/04/2013, 12h10
A1B2C3D4

Bonjour,

si le sauvegarde ne se fait pas dans l'étape 7/, sûrement il y a une exception à ce niveau (après modification). Est-ce que hibernate ne génère aucun exception ?
22/04/2013, 13h55
devyan

Citation:

Envoyé par A1B2C3D4

Bonjour,

si le sauvegarde ne se fait pas dans l'étape 7/, sûrement il y a une exception à ce niveau (après modification). Est-ce que hibernate ne génère aucun exception ?

Non il n'y a pas d'exception :(
Il ne voit simplement plus les données.
22/04/2013, 13h57
tchize_

Est-ce que tu vois les données si tu commit la transaction avant d'entamer la partie SQL? A mon avis, t'as du oublier de marquer certaines relation comme ayant une cascade ou tu a mal défini, sur un relation one to many ou many to many qui est le propriétaire de la relation (et donc qui se charge de sa mise à jour), ce n'est pas symétrique.
22/04/2013, 14h32
devyan

Citation:

Envoyé par tchize_

Est-ce que tu vois les données si tu commit la transaction avant d'entamer la partie SQL? A mon avis, t'as du oublier de marquer certaines relation comme ayant une cascade ou tu a mal défini, sur un relation one to many ou many to many qui est le propriétaire de la relation (et donc qui se charge de sa mise à jour), ce n'est pas symétrique.

Non je n'ai pas encore essayé ça ...

Mais cela pourait être quelque chose du genre vu que la requête collecte les données à partir de 3 tables dont 2 sont impactées lors de la sauvegarde en "2"/"7"
22/04/2013, 15h12
A1B2C3D4

Si le problème est au niveau ajout et modification dans les tables, tu peux vérifier le code sql généré par hibernate.
23/04/2013, 09h38
devyan

Citation:

Envoyé par A1B2C3D4

Si le problème est au niveau ajout et modification dans les tables, tu peux vérifier le code sql généré par hibernate.

Bonjour,

J'ai déjà vérifié le code SQL généré par hibernate, de ce côté tout semble correct.

J'utilise les vues "Hibernate Configurations" et "Hibernate SQL preview" pour vérifier mes HQL dans Eclipse et Oracle SQL Developer pour vérifier les résultats des requêtes générées par hibernate et mettre au point les miennes.
23/04/2013, 15h06
devyan

Citation:

Envoyé par tchize_

Est-ce que tu vois les données si tu commit la transaction avant d'entamer la partie SQL? A mon avis, t'as du oublier de marquer certaines relation comme ayant une cascade ou tu a mal défini, sur un relation one to many ou many to many qui est le propriétaire de la relation (et donc qui se charge de sa mise à jour), ce n'est pas symétrique.

Bien, j'ai fait le test (j'ai ajouté un transaction commit puis begin juste avant l'exécution de ma requête SQL récalcitrante et le TU fonctionne dans ce cas.:?)

Sinon côté mapping je ne vois rien de particulier ...
J'ai effectivement des tables maitre/détail dans l'enchainement en cause.

J'ai en fait 3 tables :
+ table principale (descriptif)
+ table détail (FK vers principale)
+ table d'affectation (FK sur principale)

Dans mon mapping :
+ table principale (j'ai un set, inverse, cascade delete sur la table detail)
+ table détail (j'ai l'identifiant de la table principale dans ma clef composite, et un many-to-one qui lui est update et insert false)
+ table d'affectation (j'ai une property sur l'id de la table principale,conformément à mon modèle de données cet id n'est pas dans ma clef composite)

Lors de mon test de modification j'ai simplement modifié un enregistrement de la table détail

Ma requête sert à collecter les données pour remplir une 4ème table à partir des informations de ces 3 là.

En écrivant ceci je me demande si cela ne serait pas plus simple de laisser Hibernate gérer les insert/update/delete de la table fille tout seul.
Actuellement je gère la table fille "à la main"
23/04/2013, 15h44
tchize_

Citation:

Envoyé par devyan

Bien, j'ai fait le test (j'ai ajouté un transaction commit puis begin juste avant l'exécution de ma requête SQL récalcitrante et le TU fonctionne dans ce cas.:?)

Remplace maintenant ton commit / begin que t'as ajouté par un session.flush() alors, t'as probablement du oublier de le faire avant ta requête sql.

Citation:

Envoyé par devyan

En écrivant ceci je me demande si cela ne serait pas plus simple de laisser Hibernate gérer les insert/update/delete de la table fille tout seul.
Actuellement je gère la table fille "à la main"

D'une manière général le sql est à réserver pour les cas où tu as de gros problèmes de performance ou pour des requêtes qui ne sont simplement pas possibles en HQL.
23/04/2013, 16h18
devyan

Citation:

Envoyé par tchize_

Remplace maintenant ton commit / begin que t'as ajouté par un session.flush() alors, t'as probablement du oublier de le faire avant ta requête sql.

J'ai déjà un flush() avant l'appel de ma fonction mais j'essaye tout de même ...

Avec session.flush() juste avant la requête SQL j'ai toujours le problème (la requête ne renvoie rien).
J'ai vérifié mon "ancien" flush et c'est en fait un hibernateTemplate.flush().

Citation:

Envoyé par tchize_

D'une manière général le sql est à réserver pour les cas où tu as de gros problèmes de performance ou pour des requêtes qui ne sont simplement pas possibles en HQL.

C'est bien mon cas, je ne sais pas convertir la requête que j'ai en HQL (c'est une requête Oracle qui contient un SELECT ... FROM ALL_OBJECTS)

Est-ce que le pb pourrait venir du fait que mon mapping ne gère pas l'insertion des champs de la sous-table ?
Je le gère "à la main" car je n'ai pas réussi à configurer le mapping pour que la table mère puisse créer les enregistrements fils (l'id du parent est dans la clef composite du fils)
24/04/2013, 11h46
devyan

Ca y'est tout fonctionne comme je le veux ...

N'ayant pas pu (réussir) à faire un mapping hibernate qui gère tout seul l'ajout/modification/suppression des enregistrements de la table détail (cascade="all-delete-orphan"), j'avais fait moi-même cett gestion dans la gestion de ma classe objet Parent avec un simple cascade="delete".
Cependant la modification ne fonctionnait pas correctement.

J'ai fini par utiliser cascade="delete-orphan" et modifié mon code pour ne plus gérer la suppression des enregistrement détail obsolètes.
Ma requête SQL voit maintenant bien la bonne version des données après modification.

Merci encore de votre aide.