If disabling QueryCache by default is fixing that bug than yes, it's fixed.
As a result of that discussion I've introduced the possibility to disable the QueryCache which is still broken. Later I've made it disabled by default. Jon would like to completely remove it, while I still have some idea on how to fix. If this is a performance issue is related to your own use of DbLinq. Try it and let us know. BTW, while QueryCache is disabled, you should not have any bug in production. May be that we will enable it by default when it will be fixed, so that updating to the new version you would not get that bug while getting (hopefully) better performance. Moreover, if you notice big performance issue in your actual project, please consider contributing by helping me fixing the QueryCache. I've no time to do this now, but I think I could help you a lot in the fix. An alternative, as Jon said, would be implementing CompliedQuery, but I think it would lead to the same difficulties we would get implementing QueryCache, so I would implement QueryCache first, then CompiledQuery. Giacomo On Fri, Jun 5, 2009 at 9:26 AM, <[email protected]> wrote: > > Hey all, > > I came across a cache problem in my ASP.NET MVC application while > using dblinq. In short, I had a method accepting a parameter which > would use that parameter in a lambda expression: > > public IEnumerable<Message> GetInbox(int userId) > { > return this.DataContext.Messages.Where(m => m.MessageTo == userId); > } > > Even when passing different user id's to the method, I would always > get the same (the first result). > (For the complete question, see it on SO: > http://stackoverflow.com/questions/951634/dblinq-cache-problem) > > So after reading some stuff on this discussion board, I came across > this post: > > http://groups.google.com/group/dblinq/browse_thread/thread/b6a5bd2020c9d48e/8a4d3bc60a6839d0?lnk=gst&q=cache+problem#8a4d3bc60a6839d0 > > I think I'm seeing the same problem here, especially what Jonathan > Pryor describes here. Something to do with closures / QueryCache. > Now, I did a new checkout of the DbLinq code (I was using one 1 month > old or so) and it seems that my problem is now fixed (as a result of > that discussion?). However, I'd like to have some more details. Is it > indeed fixed? Does this come at a huge performance cost? All I really > like is some more info, since it was a scary bug in my application and > I want to have some reassurance before it goes into production ;-) > > Thanks! > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. 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/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
