Thanks for the reply. I'll keep an eye on the performance. I might be willing to help out by fixing the QueryCache, but I have absolutely no idea what has to be done, e.g the required work, time, and skill needed. Where can I go for more details?
On 5 jun, 10:46, Giacomo Tesio <[email protected]> wrote: > 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/b6a5bd2020... > > > 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!- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
