Discussion :

[Philenain]

Bonjour,

Cela fait maintenant 2 semaines que je dois refaire toute la couche de données d'un projet en utilisant NHibernate.

Sur les objets "simple" je n'ai aucuns problèmes et à priori toutes mes actions fonctionnaient aussi sur des hiérarchies d'objets (des objets qui contiennent des collections d'objets).
Seulement voilà, je me suis aperçut d'un "petit" souci :
Quand je supprime un objet "Enfant" de la collection d'un objet "Parent" et que je sauvegarde l'objet parent, NHibernate ne fait que supprimer la clef étrangère de l'objet "Enfant" en base de données...

Effectivement les objets ne remontent plus via les méthodes de sélections de NHibernate mais à mon avis ce ne doit pas être le comportement normal .

Voilà à qui ressemble le mapping de mes classes "Parent" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="MaDLL"
                   namespace="MaDLL.Entities">
<class name="MaDLL.Entities.Parent" table="Parent">
<id>…</id>
 <bag name="Enfants" cascade="all-delete-orphan" >
      <key column="idParent"/>
      <one-to-many class="MaDLL.Entities.Enfant"/>
  </bag>
</class>
</hibernate-mapping>

Et celui de mes classes « Enfant » :

Code :

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

1
2
3
4
5
6
7
8
9
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="MaDLL"
                   namespace="MaDLL.Entities">
<class name="MaDLL.Entities. Enfant  " table=" Enfant  ">
	<id>…</id>
    <property name="Nom" column="nom" />
    <property name="Prenom" column="prenom" />
</class>
</hibernate-mapping>

Pour ce qui est du code utilisé pour la sauvegarde :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public void Sauvegarder(T element)
        {
            StartTransaction();
 
            try
            {
                Session.SaveOrUpdate(element);
                Session.Flush();
 
                CommitTransaction();
            }
            catch (Exception ex)
            {
                RollBacktTransaction();
                throw ex;
            }
        }

Donc voilà si quelqu’un voit comme ça la boullette qui doit être énorme j’imagine, ça m’interresse car je m’arrache les cheveux là :p

[tomlev]

Quand je supprime un objet "Enfant" de la collection d'un objet "Parent" et que je sauvegarde l'objet parent, NHibernate ne fait que supprimer la clef étrangère de l'objet "Enfant" en base de données...

Ca me semble normal : en enlevant l'enfant de la collection du parent, tu ne dis pas "supprime l'objet enfant", mais "dissocie l'enfant du parent". Tu pourrais vouloir l'ajouter ultérieurement à un autre parent, ce qui ne serait pas possible s'il avait été supprimé

Code :

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

1
2
3
4
5
6
 
            catch (Exception ex)
            {
                RollBacktTransaction();
                throw ex;
            }

Argh...
Il faut jamais faire "throw ex", mais juste "throw", sinon tu réinitialises la pile de l'exception et tu ne sais plus d'où elle vient au départ. Par contre tu peux aussi "l'envelopper" dans une autre exception en tant que InnerException :

Code :

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

throw new ApplicationException("Erreur lors de la mise à jour", ex);

Donc voilà si quelqu’un voit comme ça la boullette qui doit être énorme j’imagine, ça m’interresse car je m’arrache les cheveux là :p

Y a pas de boulette... comme je l'ai dit plus haut, ce comportement est normal

[Philenain]

Dabord merci de ta réponse

Oui c'est vrai qu'en y repenssant c'est logique en effet.

Pour le "throw ex" j'utilise d'habitude une exception personalisée, mais, ayant l'interdiction de transmettre le moindre bout de code de l'application à l'extérieur, j'ai dût retaper vite fait un exemple et celà m'a échappé .

Don encore merci pour ta réponse et bonne continuation

[B.AF]

Bonjour,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="MaDLL"
                   namespace="MaDLL.Entities">
<class name="MaDLL.Entities.Parent" table="Parent">
<id>…</id>
 <bag name="Enfants" cascade="all-delete-orphan" >
      <key column="idParent"/>
      <one-to-many class="MaDLL.Entities.Enfant"/>
  </bag>
</class>
</hibernate-mapping>

Et celui de mes classes « Enfant » :

Code :

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

1
2
3
4
5
6
7
8
9
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="MaDLL"
                   namespace="MaDLL.Entities">
<class name="MaDLL.Entities. Enfant  " table=" Enfant  ">
	<id>…</id>
    <property name="Nom" column="nom" />
    <property name="Prenom" column="prenom" />
</class>
</hibernate-mapping>

Pour ce qui est du code utilisé pour la sauvegarde :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public void Sauvegarder(T element)
        {
            StartTransaction();

            try
            {
                Session.SaveOrUpdate(element);
                Session.Flush();

                CommitTransaction(); 
           }
            catch (Exception ex)
            {
                RollBacktTransaction();
                throw ex;
            }
        }

Oui c'est normal, mais, je ne comprends pas ce que le session.Flush() vient faire au milieu d'une transaction.
Tu peux le supprimer, ça t'évitera de mettre une bombe à retardement dans ton code.

Dans la même veine, tu peux aussi logger le SQL en utilisant l'option showsql, et regarder le sql généré par ton update.

[Philenain]

D'abord merci pour ta réponse,

Le coup du session.flush() c'est un reste d'un bout de code que j'avais tenté pour résoudre un soucis que j'ai eu, et que j'ai toujours d'ailleurs, avec NHibernate.

En fait: j'ai une grosse tache dans mon code, une manip' que dois faire souvent que je trouves débile :
A chaque fois que je tentes une action de CRUD avec un objet chargé par NHibernate qui a une collection (<BAG />) d'objets enfant j'ai obligatoirement un message qui me dit que l'objet ne peut pas être utilisé par deux objets session.
Et la seule parade que j'ai trouvé: c'est de faire des méthode qui me créé des copies de mes objets entités(soit de nouvelles instances de collections d'objets enfants avec un parcours de collection pour la remplire...), soit du code bien porcasse, pas opti pour un sou...

Enfin, vu le code que j'ai produit pour l'instant (la moitié ne me plait pas) les astuces que je doit utiliser une fois sur deux avec des objets "hiérarchiques", je pense que je vais prendre une prestation de soutiens pour NHibernate avant qu'il n'y ait trop de code de produit.

Encore merci pour ces réponses

[B.AF]

D'abord merci pour ta réponse,

Le coup du session.flush() c'est un reste d'un bout de code que j'avais tenté pour résoudre un soucis que j'ai eu, et que j'ai toujours d'ailleurs, avec NHibernate.

En fait: j'ai une grosse tache dans mon code, une manip' que dois faire souvent que je trouves débile :
A chaque fois que je tentes une action de CRUD avec un objet chargé par NHibernate qui a une collection (<BAG />) d'objets enfant j'ai obligatoirement un message qui me dit que l'objet ne peut pas être utilisé par deux objets session.
Et la seule parade que j'ai trouvé: c'est de faire des méthode qui me créé des copies de mes objets entités(soit de nouvelles instances de collections d'objets enfants avec un parcours de collection pour la remplire...), soit du code bien porcasse, pas opti pour un sou...

Enfin, vu le code que j'ai produit pour l'instant (la moitié ne me plait pas) les astuces que je doit utiliser une fois sur deux avec des objets "hiérarchiques", je pense que je vais prendre une prestation de soutiens pour NHibernate avant qu'il n'y ait trop de code de produit.

Encore merci pour ces réponses

Effectivement, derrière l'apparente facilité de la génération de code et des tutos, les ORM sont tous complexes avec un lot important de notions et de comportements à appréhender.