A note: this is just part of the code required to fix QueryCache, but it's the more required and less obvious (at least in my implementation idea).
The other required changes would be quite trivial, and I could do them easily when the visitor would be done. Giacomo On Tue, Jun 9, 2009 at 2:18 PM, Giacomo Tesio <[email protected]> wrote: > If you'd really to become a DbLinq contributor by fixing the QueryCache > issue you should write an ExpressionChain visitor which is able to traverse > ExpressionChain as ExpressionDispatcher.Analyze() does. > > This should not be that complex (assuming you are able to write an > ExpressionTree visitor, if not you car read this > http://msdn.microsoft.com/en-us/library/bb882521.aspx ) > > A DbLinq DbLinq.Data.Linq.Sugar.ExpressionChain is a linked list of > expressions which flatten the Expression Tree that rapresent the query in a > structure easier to handle (when you understand it) > > > The visitor entry point shoul have such a signature: > > Func<ExpressionChain, Expression> BuildExpressionExtractor(ExpressionChain > chain, Expression parameterToExtract) > > In the implementation you should iterate the chain to find an Expression > which ToString() result would exactly match the parameterToExtract. > > Than you should build an Expression<Func<ExpressionChain,Expression>> that > whould be able to extract in the fastest possible way the > parameterToExtract. > > For Example if the parameterToExtract match exactly the item 2 in the > chain, the first part of the lambda you should build would be > Expression<Func<ExpressionChain,Expression>> toReturn = (ExpressionChain c) > => c[2]; > > Supposing this would be a MethodCallExpression and the parameter required > being the first, the expression produced should become something like > Expression<Func<ExpressionChain,Expression>> toReturn = (ExpressionChain c) > => ((MetodCallExpression)c[2]).Arguments[0]; > > > I know that this could be quite easy or quite complex depending on your > current skills. > > > For my own skills it would be nor easy nor too complex, but I've no time to > write this code now (even if planned for when my company will need such > performances) > > > I hope moreover that this would be doable, but this is something that > Pascal only could confirm > > > > Giacomo > Pascal: what do you think about this implementation? > > > > > On Fri, Jun 5, 2009 at 11:17 AM, <[email protected]> wrote: > >> >> 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 -~----------~----~----~----~------~----~------~--~---
