Refresh of entity that just has been saved clears collections of the entity

Thanks for the explanation for expected behaviour of Save() and Persist(). Having only read 'Hibernate in Action' from front to back, I was not aware of the differences between Save() and Persist(). I how have also read your blog posts and parts of 'Java Persistence with Hibernate' to get a further understanding. This still leaves me with some questions:

The complications of using identity columns (hard to avoid at times when using legacy databases) with the NHibernate session as unit of work focus seem to come down to the correct timing of Flush() calls to sync the session content with the database. When using Flushmode.Manual with the intention to only hit the database at the end of the unit of work I can see the issues that the identity id generator causes. However, when using Flushmode.Auto I would expect NHibernate to be smart enough to detect when it should Flush(), even it needs to be earlier than ideal. That is the behaviour I came to expect from reading the (printed) Hibernate docs.

Flushmode.Auto indicates that NHibernate will flush before queries are executed. If an id generator implies an INSERT+SELECT, than it seems not unreasonable to think that the logical (or at least consistent) consequence would be that such an insert should trigger an auto flush.

In the mean time, manual flushing does the job as a workaround, so the severity of this issue can be downgraded as far as I am considered.

Kind Regards,
Gerke.

I would like to be more clear.
The ISession implements UnitOfWork.
http://martinfowler.com/eaaCatalog/unitOfWork.html
The unitOfWork.Commit is the session.Flush.

In practice if you never call Flush NH never hit DB.
The only one exception is cause by identity and identity-style generators.
http://fabiomaulo.blogspot.com/2008/12/identity-never-ending-story.html
http://fabiomaulo.blogspot.com/2009/02/nh210-new-generators.html
http://fabiomaulo.blogspot.com/2009/02/nh210-generators-behavior-explained.html

The implementation of UoW is one of the bases of NH, we can't break it to support your use-case.

Here you should use Persist instead Save because Save do any actions during Flush where Persist execute any action immediately.
The problem is that cascades to associated instances and not aggregation with components.

More exactly your use case can't work without an explicit flush... the Parent is saved immediately only because you are using identity.
Without an explicit Flush before refresh your test can't work (at the end you are doing a lot of work in the same session/transaction).

Not sure but I strongly suspect this is related to https://nhibernate.jira.com/browse/NH-1601

Attaching unit test for this bug report.