Reputation: 21
Anyone know why EF6 would be needlessly re-casting an Int16 to smallint? Using the logging function, I see it performed the following query:
SELECT
[Project1].[LabelName] AS [LabelName], Project1.Usage, Project1.FacilityID
FROM ( SELECT
[Extent1].[LabelName] AS [LabelName],
[Extent1].[Usage] AS [Usage],
extent1.facilityid
FROM [dbo].[Label] AS [Extent1]
WHERE (0 = [Extent1].[DeleteInd])
AND ([Extent1].[FacilityID] IN (cast(1 as smallint), cast(5 as smallint)))
AND (([Extent1].[LabelName] LIKE @p__linq__0 ESCAPE '~') OR ([Extent1].[LabelName] LIKE @p__linq__1 ESCAPE '~'))
) AS [Project1]
ORDER BY [Project1].[Usage] DESC
-- p__linq__0: '%test%' (Type = AnsiString, Size = 8000)
-- p__linq__1: 'test%' (Type = AnsiString, Size = 8000)
-- Executing at 12/6/2013 4:08:49 PM -08:00
-- Completed in 16 ms with result: SqlDataReader
This is the Linq query:
Context.Database.Log = Console.Write;
var labels = (from label in Context.Labels
where label.DeleteInd == false &&
Settings.FacilitySearch.Contains(label.Facility.FacilityID) &&
(label.LabelName.Contains(searchText) || label.LabelName.StartsWith(searchText))
orderby label.Usage descending
select label.LabelName);
return labels.ToList();
EF knows the FacilityId is smallint <-> Int16 (would show a picture but not enough reputation points :-/)
project: C# WinForms .NET 4.0 Windows 7 SP1 Visual Studio 2010
Upvotes: 2
Views: 671
Reputation: 156524
I'm guessing that this conversion isn't required in this particular case, but it was simpler to write code that always performs casts, and assume that SQL Server will probably optimize it out anyway. The developers probably figured it's better to generate needlessly complex SQL than to maintain needlessly complex code.
Upvotes: 1