Guillaume Saint Etienne 's Blog

Le problème vient d’Hibernate, qui a été conçu dans un certain état d’esprit si l’on peut dire, pour certains types d’applications et de façon de programmer.

Il semblerait que ses concepteurs viennent de l’école N-tiers des applications connectés comme ce que l’on peut trouver avec des clients riches Java ou Windows.

Nous faisons ici du Web (1.0 ou 2.0 peu importe). Et donc les objets que nous manipulons n’ont d’espérance raisonnable de vie que le temps d’un traitement coté serveur et un aller/retour d’information entre le navigateur client (ce serait valable aussi pour du smart client) et les instances de traitement coté serveur (services/métier/domaines). Et en plus nous utilisons un moyen de binding entre les objets graphiques Web (un DetailView de ASP.Net 2.0) et les objets NHibernate.

Du coup, la méthode Update disponible dans NHibernate, ET DANS LA MESURE OU NOUS MAINTENONS LA SESSION NHIBERNATE EN MEMOIRE (sur le tas, via un Singleton qui renvoie une instance statique, ou dans l’espace mémoire de Session ASP.NET [mais je n’ai pas testé ce cas] ), nous renvoie une exception qui dit : « vous ne pouvez pas faire d’update sur cet objet car il est différent de celui qui existe déjà dans votre session NHib ».

Que faut-il comprendre ?

Nhib raisonne dans sa logique de session, et si vous prenez (Get ou Load) un objet de données, c’est pour le manipuler lui dans la même session, le modifier, le supprimer. Cela a du sens, en particulier pour assurer une vrai bonne transaction et pour éventuellement poser des verrous (méthode Lock sur l’objet Session de NHib).

Voir la documentation complète à ce sujet http://www.hibernate.org/hib_docs/nhibernate/html/transactions.html
Et en français http://www.hibernate.org/hib_docs/v3/reference/fr/html/objectstate.html#objectstate-detached

Lock permet de réassocier un objet qui est resté en mémoire lors d’une nouvelles session NHibernate.
Mais nous avons le problème inverse. Nous avons gardé la même session (voir plus haut) mais pas le même objet. EN effet, si on laisse faire le Two-Way Databinding, à chaque exécution de la page qui contient le composant webform DetailView , l’objet de données est régénéré. Il suffit de poser un point d’arrêt sur DetailsView1_ItemCreated pour s’en rendre compte. Cet événement est même déclenché 2 fois lorsqu’on est en mode « Edit » du DetailView et que l’utilisateur vient de valider sa saisie.
Nous le savons bien maintenant : on n’a jamais assez le contrôle sur un widget tiers ou sur du code généré par un wizard et tout ce qui peut s’apparenter à un automatisme.

Il faut donc mettre les mains dans le cambouis, et pallier soi-même à ce genre de défaut.
Principe : il faudrait lors du mécanisme d’update, assumer le fait que l’objet de données qui nous est passé n’est pas le même que celui qui a été utilisé pour faire la lecture (Load renvoie un objet A). Donc dans la méthode update, il nous faudra relire depuis la base un nouvel objet de données (appelons le C), lui passer les informations obtenues depuis l’objet qui contient les donnée modifiées (objet B qui, lui, est généré automatiquement par le 2-way binding du DetailView) et sauver l’objet C ce qui satisfait au fonctionnement NHib.

Si nous passions au code ?

La métohde de notre objet de domaine utilisée comme méthode d’update dans la déclaration du tag DataSourceObject aura cette tête (ce corps plutot):

[DataObjectMethod(DataObjectMethodType.Update)]
public bool Modify2(X.DataEntityObjects.TRestaurants modifiedData)
{

ITransaction tx = null;
try
{
tx = nHibSession.BeginTransaction();

TRestaurants originalData = (TRestaurants)nHibSession.Get(typeof(TRestaurants), modifiedData.Id);
if (originalData == null)
{
tx.Rollback();
return false; //on ne peut pas faire la transaction
}

nHibSession.Lock( originalData , LockMode.Upgrade);

originalData.Adresse = modifiedData.Adresse;
originalData.CodePostal = modifiedData.CodePostal;
originalData.Gerant = modifiedData.Gerant;
originalData.Nom = modifiedData.Nom;
originalData.Pays = modifiedData.Pays;
originalData.Ville = modifiedData.Ville;

nHibSession.Update(originalData);
tx.Commit();

}
catch (HibernateException ex)
{
tx.Rollback();
throw ex;
}
return true;
}

On voit donc qu’on est obligé de ré- obtenir un objet de données correspondant à la même clef primaire (modifiedData.Id) que l’objet modifié :

TRestaurants originalData = (TRestaurants)nHibSession.Get(typeof(TRestaurants), modifiedData.Id);

Puis transférer par valeur sur chaque propriété qui nous semble intéressante (cela va dépendre de votre contexte)

originalData.Adresse = modifiedData.Adresse;

ensuite on procède à la mise à jour de l’objet de données :

nHibSession.Update(originalData);
tx.Commit();

On remarque que on ne passe pas à Hibernate l’objet modifiedData, on ne fait juste qu’exploiter les informations qu’il contient.