Is this necessary within a TransactionScope? Thanks, J.
On Tuesday, April 10, 2012 8:12:48 PM UTC+1, Gunnar Liljas wrote: > > You may need an explicit transaction (BeginTransaction) for autoflushing > to work as expected. > > /G > > 2012/4/10 John T > >> Hi, >> >> Yes, I have executed the code exactly as written - and it does not work. >> Sequence contains no elements on the Single(). :) >> >> Regards, >> John. >> >> On Tuesday, April 10, 2012 5:15:16 PM UTC+1, Oskar Berggren wrote: >>> >>> Den 10 april 2012 16:27 skrev John Thornborrow: >>> >>> > Hi, >>> > >>> > We are using Automatic flush mode, but it is very explicitly and >>> precisely >>> > not flushing when we query. The code example I posted in my previous >>> post is >>> > factually correct, the second line (i.e. query) will/does throw an >>> > exception. >>> > >>> > Cannot viably use Get()/Load() because the Query is composed further >>> up the >>> > chain, thus the Law of Demeter kicks in and well.. it's pretty ugly >>> for the >>> > domain to know what is and isn't a concern of the DB anyway. :) >>> > >>> > Though I must ask.. why implement a Cache if it is not going to be >>> > Queryable? >>> >>> >>> The L1 cache is more like the "working data set" - it contains the >>> objects currently tracked by the session. This has multiple purposes: >>> avoiding object duplication, knowing which objects to persist when >>> flushing changes, and performance. NH relies on the database to >>> execute queries, returned objects may still come from the L1 cache if >>> they were already loaded. >>> >>> >>> Regarding the oversimplified code example you gave, have you executed >>> that code exactly as written? >>> >>> >>> /Oskar >>> >> >> On Tuesday, April 10, 2012 5:15:16 PM UTC+1, Oskar Berggren wrote: >>> >>> Den 10 april 2012 16:27 skrev John Thornborrow: >>> >>> > Hi, >>> > >>> > We are using Automatic flush mode, but it is very explicitly and >>> precisely >>> > not flushing when we query. The code example I posted in my previous >>> post is >>> > factually correct, the second line (i.e. query) will/does throw an >>> > exception. >>> > >>> > Cannot viably use Get()/Load() because the Query is composed further >>> up the >>> > chain, thus the Law of Demeter kicks in and well.. it's pretty ugly >>> for the >>> > domain to know what is and isn't a concern of the DB anyway. :) >>> > >>> > Though I must ask.. why implement a Cache if it is not going to be >>> > Queryable? >>> >>> >>> The L1 cache is more like the "working data set" - it contains the >>> objects currently tracked by the session. This has multiple purposes: >>> avoiding object duplication, knowing which objects to persist when >>> flushing changes, and performance. NH relies on the database to >>> execute queries, returned objects may still come from the L1 cache if >>> they were already loaded. >>> >>> >>> Regarding the oversimplified code example you gave, have you executed >>> that code exactly as written? >>> >>> >>> /Oskar >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/nhusers/-/uraL59S5BY8J. >> >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "nhusers" group. To view this discussion on the web visit https://groups.google.com/d/msg/nhusers/-/jZYrwqvtmT0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
