CODEWITHSUNDEEP
c#databasenhibernateorm
TheMonkeyMan
TheMonkeyMan

Reputation: 9152

Nhibernate Refresh IEnumerable

I have two Classes

public class Notification
{
    public virtual Guid ID { get; set; }
    public virtual IEnumerable<Message> Messages {get;set;}
}

public class Message
{
    public virtual Guid ID { get; set; }
    public virtual string Message { get; set; }
}

I have two .ascx controls on my page and one invokes a Bind on the other through a public method. Now if I add a row to the Message List and then run my bind method that simply Gets a notification by ID and returns messages. I dont get the newly added message. I must refresh the page again before it gets this data.

Is there something about the IEnumerable caching or how do I force it to go back to the Database I run Session.Get<> but it does not have the effect I want.

I have also tried

Session.Evict
Session.Refresh

Upvotes: 2

Views: 1331

Answers (1)

quetzalcoatl
quetzalcoatl

Reputation: 33566

Please check the Q and A posted below, I think their case is very similar to yours. Maybe by simply changing he way you are handling your collections

Reload association/related collection in NHibernate
What's the best way to refresh entities in nhibernate
https://forum.hibernate.org/viewtopic.php?f=1&t=968923

The main problem is that the NH doesn't have a "collection" notion. All it is about is handling objects and maping them to tables. If you follow a relation, NH generates a query, downloads list of objects, thinks it has done and is happy about that. You get a collection of Objects that were returned by query. To re-read the collection you actually have to re-run the query. This is what Queries and Criteria are about: to prepare something that you can reuse for refreshing your collections. Refreshing - by re-fetching them from DB.

IIRC, the NH tracks objects. This means that if a first run of the query returned objects A,B,C and put them in a List<>, then the hext run returned A,C,D,E and returned them in some other List<>, then the objects A anc C will be all the same objects as in the first time. There will be no object-cloning unless you use different NH sessions. Of course it is up to you to take care of both List<> - that is, you have to decide how to merge them in to one thing shown to the user. usually you will want to wither drop the first and use only the most fresh one to indicate instantly that 'B' as removed, or to merge them both pretending that 'B' was never removed and silently patching that on the commit.

Upvotes: 1

Related Questions