2010-07-19 5 views
0

Après avoir récupéré une entité, j'en change une propriété. Ensuite, je récupère la même entité. Comment puis-je dire Nhibernate, qu'il doit mettre à jour l'entité avant de charger l'entité?NHibernate FlushMode: Comment configurer NHibernate pour mettre à jour automatiquement une entité

Voici le code:

EmployeeRepository employeeRepository = new EmployeeRepository(); 
Employee employee = employeeRepository.GetById(4); 
employee.LastName = "TEST!!!"; 
Employee employee2 = employeeRepository.GetById(4); 

Actuellement Nhibernate ne font pas une mise à jour dans mon programme. Je pensais que le simple réglage du FlushMode sur Auto mettrait automatiquement à jour l'entité.

EDIT L'arrière-plan est que j'essaye de reprdouce ce comportement dans une autre application. Il n'y a pas de méthode de sauvegarde! Juste ce code. La version de NHibernate est vraiment ancienne, c'est la version 1.2.1.4000. Peut-être qu'il y a la capture.

Lorsque je définis le FlushMode dans l'application brownfield sur Commit, aucune instruction de mise à jour n'est générée.

Mais dans mon propre projet je ne peux toujours pas reproduire ce comportement "automatique".

Répondre

3

Les deux appels à employeeRepository utilisent-ils finalement la même instance NHibernate ISession? Si tel est le cas, ils renverront le même objet et la valeur LastName mise à jour sera reflétée. Si ce n'est pas le cas, vous devrez vous assurer de disposer de votre instance ISession chaque fois pour tirer parti du rinçage automatique.

+0

alors s'il vous plaît regardez mon édition – Rookian

+0

alors quand j'utiliser le même "ISeesions" NHibernate appellera automatiquement une déclaration sql de mise à jour, parce que j'ai le FlushMode mis à l'auto? – Rookian

+0

Non, il mettra en cache l'objet modifié en mémoire. –

1

Selon the documentation pour le FlushMode par défaut Auto:

Le ISession est parfois vidées avant l'exécution de requêtes afin de faire en sorte que les requêtes ne reviennent jamais état périmé. C'est le mode de vidage par défaut.

Vous devez donc vider manuellement la session pour vous assurer que vos modifications sont conservées avant de relire l'objet.

EmployeeRepository employeeRepository = new EmployeeRepository(); 
Employee employee = employeeRepository.GetById(4); 
employee.LastName = "TEST!!!"; 
session.Flush(); 
Employee employee2 = employeeRepository.GetById(4); 

Si votre référentiel utilise le même ISession pour les appels (comme il devrait imo) alors employé 4 sera récupéré à partir du cache et ont le changement. Cependant, la modification n'aura pas encore été conservée dans la base de données.

Si vos méthodes GetById de référentiel utilisent une nouvelle session pour chaque appel, elles seront toujours envoyées à la base de données pour récupérer l'employé. Si vous supprimez la session dans la méthode, vos objets sont renvoyés comme détachés d'une session. Cette stratégie va à l'encontre de l'objectif de NHibernate et la relègue à un simple outil d'accès aux données.

+0

"L'ISession est parfois vidée" Qu'est-ce qui signifie parfois: D? Eh bien, quand Nhibernate appelle une instruction SQL update? Je n'ai pas compris cela correctement. – Rookian

+0

Je ne sais pas avec certitude. Mon attente est que si vous récupériez et modifiiez un employé puis que vous faisiez un select sur la table, NHibernate viderait d'abord la session pour que la requête renvoie des résultats cohérents. Cela ne peut fonctionner que si les opérations sont effectuées dans la même session. Obtenir un objet par clé primaire est une histoire différente; dans ce cas, NHibernate le récupèrera du cache. –

+0

J'ai maintenant récupéré l'entité via l'API ICriteria en implémentant une méthode GetByName, mais il n'y a toujours pas d'instruction de mise à jour. J'ai la même session, FlushMode = auto. Qu'est-ce que j'ai tort? – Rookian

Questions connexes