As far as I remember, some week ago I've "fixed" a bug about the querycache: in the expression comparer I compare expression.ToString().
If the expression cached contains the parameter value too, this "fix" would be a bug. But, the fact itself that the query cache contains parameter's values would make the query cache far less useful than what it should be. Giacomo On Fri, May 8, 2009 at 12:47 PM, Pascal Craponne <[email protected]> wrote: > Nope, but I can testify that this cache worked, when I wrote it :) > > > On Fri, May 8, 2009 at 00:57, Jonathan Pryor <[email protected]> wrote: > >> I think QueryCache is broken. I'm quite confused about the whole thing, >> actually... >> >> What I'm trying to do is "port" NerdDinner to Mono/Linux. In an ideal >> world, nothing would need to change, but this isn't an ideal world (as I'm >> finding plenty of issues in Mono's System.Data.Linq i.e. DbLinq to keep me >> less than happy, e.g. the .Count() issue I asked about a few days ago). >> >> So what I'm seeing happen is this: the url e.g. >> http://localhost:8080/Dinners/Details/1 contains detail information about >> the dinner with ID 1. Simple enough. The problem is after I hit this URL, >> if I go to *any other* dinner detail page (e.g. >> http://localhost:8080/Dinners/Details/2),<http://localhost:8080/Dinners/Details/2%29,>I >> get the information for the >> *first* page I visited. >> >> This is, of course, incredibly annoying. >> >> What makes me think QueryCache is the problem is that if I change >> QueryCache.GetFromSelectCache() to always return null (i.e. kill the >> cache), everything Just Works. >> >> So I'm quite sure that QueryCache is the problem. What I'm not sure about >> is why I can't reproduce this in the unit tests (which is *really*annoying). >> >> What I do know is that when I view the log output, the generated queries >> have the wrong values. For example, my annotated log output: >> >> # Went to: http://localhost:8080/Dinners/Details/1 >> <http://localhost:8080/Dinners/Details/3> >> # Getting Dinner: 1 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [1] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> # Got Dinner: 1 >> >> # Now, within DinnerRepository.GetDinner(), I sanity check with: >> # id = 3; >> # var a = db.Dinners.Single(d => d.DinnerID == id); >> # id = 4; >> # var b = db.Dinners.Single(d => d.DinnerID == id); >> # Console.Error.WriteLine("# a='{0}'; b='{1}'", a.DinnerID, >> b.DinnerID); >> # Sanity check output... >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [3] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> # a='3'; b='4' >> # OK, sanity check is sane. >> >> # At this point, things are sane. >> >> # Went to: http://localhost:8080/Dinners/Details/2 >> <http://localhost:8080/Dinners/Details/3> >> # Getting Dinner: 2 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> # Got Dinner: 4 >> # Sanity check... >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> # a='4'; b='4' >> >> # Uh, wtf? Notice that even though we're going to 2, >> # we see [4] in the output. Furthermore, my >> # NerdDinner.GetDinner() sanity check is also returning >> # the *same* Dinner, even though it shouldn't. >> >> # Went to: http://localhost:8080/Dinners/Details/3 >> # Getting Dinner: 3 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> # Got Dinner: 4 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> SELECT TOP (2) [DinnerID], [Title], [EventDate], [Description], [HostedBy], >> [ContactPhone], [Address], [Country], [Latitude], [Longitude] >> FROM [dbo].[Dinners] >> WHERE [DinnerID] = @id >> -- @id: Input Int32 (Size = 4; Prec = 0; Scale = 0) [4] >> -- Context: SqlServer Model: AttributedMetaModel Build: 3.5.0.0 >> # a='4'; b='4' >> >> # and things are still hosed. >> >> I'm largely clueless here, not being nearly familiar enough with the >> code. All I'm *sure* of is that killing the query cache makes things >> work. >> >> My *suspicion* is that SelectQuery is actually at fault, as >> SelectQuerycontains the input parameters ( >> SelectQuery.InputParameters), which are used ~directly in the resulting >> SQL query (see SelectQuery.GetCommand(), which adds each input Parameterto >> Command.Parameters, and uses parameter.GetValue() to obtain the actual >> value. So it *appears* that SelectQuery is not only caching the query >> itself, but the parameters used with the query as well, which is absolutely >> *bad*. >> >> But if this were truly the case, then this would be visible in the unit >> tests (e.g. ReadTest.A5_SelectSingleOrDefault()), and I'm not seeing it >> in the unit tests. >> >> Thoughts? (Or better, actual fixes?) >> >> - Jon >> >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
