+2  A: 

You are setting the id but it's an Identity. You should not set it, SQL does that for you.

Instead of creating a new session use the same one, and retrieve using Get instead of Load.

On the difference between Load and Get: http://ayende.com/Blog/archive/2009/04/30/nhibernate-ndash-the-difference-between-get-load-and-querying-by.aspx

pedro
This is odd. It saved the object (like it was doing before), then gave me a "row not found" exception when I tried to Load it. The important point is that I could make my assertion work be doing what you said and adding Cascade to parent of this Application entity. I will do some more testing to make sure everything is working.
tucaz
+1 about identity id. -1 about session.Clear() since it makes sense to clear session while testing to make sure you hit db and not cache.
dotjoe
pedro, I have .Clear() in my example because PersistenceSpecification.VerifyTheMappings uses it so I needed it to repro the problem.
tucaz
@Pedro: Creating a new session asserts that the Load() method hits the database. Using the same session, NHibernate could return the cached entity. Anyhow, it is only adviseable to use the same session within one and only context, either a WinForm or a WebPage. After this context is no longer viable, the session should be released in favor of another new one. Using the same session for too long cause memory leaks from the ISession interface as it keeps tracks of the entities manipulated.
Will Marcouiller
@Will: Clear will completely evict all objects from the session cache. It could still be retrieved from the second level cache, if you did set it up, but considering it's a test wouldn't you say that Clear is enough ?
pedro
A: 

Your using two differen ways to create the session?

NHibernateHelper.CreateSession();

and

_sessionFactory.OpenSession();

maybe you should try _sessionFactory.OpenSession(); to get a session for retrieval.

MoJo2600
_sessionFactory is static inside NHibernateHelper so they are using the same Factory to create the session.
tucaz
A: 

you don't need to flush manually since the framework will notice that you perform a search on an entity of which there are still pending changes, those changes will be flushed before the get, in this I think that idMyApp will be 1 instead of the right generated id from the database....causing your get code to fail...

Tim Mahy
He's creating a new session, though, and that new session *won't* notice those unflushed changes.
Isaac Cambron
+1  A: 

I think you're grabbing Id out of myApp too early. Try doing _session.Flush() before looking up Id. Since you're using an Identity Generator, NHibernate bubbles the generated Id back up to your object, but that doesn't happen until the session is flushed (usually at transaction commit-time).

David Rubin