tag:blogger.com,1999:blog-24760385.post1277863162872557471..comments2007-10-09T00:25:48.471-07:00Comments on NET Progress: Query Errors and Identity MapJohn Ruskhttp://www.blogger.com/profile/06542045668842804974noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-24760385.post-54713161925939468242007-10-09T00:25:00.000-07:002007-10-09T00:25:00.000-07:00True. That's what I was trying to get at with "op...True. That's what I was trying to get at with "option 2" above. I do agree that scanning to include all now-matching ones (ones which did <I>not</I> actually come back from the DB) would indeed have performance issues.<BR/><BR/>That's why I added "option 4", which is <I>deliberately</I> only half the solution. It is only about rejecting "bad" records, weeding out the ones which did come back from the DB but which (in memory) no longer match the query that retrieved them.<BR/><BR/>That can be done efficiently, as follows:<BR/><BR/>foreach row in result set<BR/>{<BR/> if row already in identity map<BR/> {<BR/> check if the in-memory object still matches the query<BR/> }<BR/> else<BR/> {<BR/> // it was not already in memory, so no need to do an in-memory test<BR/> }<BR/>}<BR/><BR/>In other words, the in-memory test only runs for objects which were in fact in memory before the query runs. In many situations, that will only be a small minority of the rows. <BR/><BR/>The value of this approach is that you can ask for a list of "Smiths" and then process it safe in the knowledge that they are indeed "Smiths". They might not be <I>all</I> the Smiths that <I>exist</I> (since others may also exist in memory, as you said); but they will <I>all be</I> Smiths. Not Joneses.<BR/><BR/>To me, there is a big difference between accidently running Smith logic on a Jones; versus missing out some Smiths when I run my Smith logic. The former is plain erroneous; while the latter is akin to <I>someone else</I> saving a new Smith while you are working - it's not very different from the "normal" concurrency issues in multi-user systems.John Ruskhttp://www.blogger.com/profile/06542045668842804974noreply@blogger.comtag:blogger.com,1999:blog-24760385.post-27673912153668814462007-10-08T07:22:00.000-07:002007-10-08T07:22:00.000-07:00Very interesting, I hadn't gone much beyond consid...Very interesting, I hadn't gone much beyond considering what LINQ does to what it should do.<BR/><BR/>The problem with post-processing the identity map to reject non-matching records is that you'd also have to scan them to include now-matching ones too. There would no doubt be performance implications here.<BR/><BR/>Every new technology to solve problems brings a few new ones to the party.<BR/><BR/>[)amienTranthttp://www.blogger.com/profile/07644693108706722203noreply@blogger.com