I've tried some test, and it seemed to be working. At least, it's not what I was thinking.
Have you finally found a failing test for this use case? It seem related to web environment. Was it running on IIS? Giacomo On Mon, May 11, 2009 at 12:26 AM, Giacomo Tesio <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
