Does anyone know of a definitive list of LINQ to SQL query limitations that are not trapped at compile time, along with (where possible) workarounds for the limitations?
The list we have so far is:
- Calling methods such as
.DateonDateTime- no workaround found
string.IsNullOrEmpty- simple, just use
== ''instead
- simple, just use
.Last()- we used
.OrderByDescending(x => x.WhateverProperty).First()
- we used
Basically, that list is huge… it is everything outside of the relatively small set of things that are handled. Unfortunately, the Law Of Leaky Abstractions kicks in, and each provider has different answers…
LINQ-to-Objects will do anything (pretty much), since it is delegates; LINQ-to-SQL and Entity Framework have different sets of support.
In general, I’ve had a fair amount of success using the
DateTimeproperties etc – but in reality, you’re going to have to ensure that your query expressions are covered by unit tests, so that if you ever change providers (or the provider gets updated) you know it all still works.I guess one view is to think in terms of TSQL; there is no
BOTTOM n, but there is aTOP 1(re theOrderByDescending); In terms ofstring.IsNullOrEmpty, you could be quite literal:foo.Bar == null || foo.Bar == ''; and withDateTime.Dateyou can probably do quite a bit withDATEPART/ the various components.Another option with LINQ-to-SQL is to encapsulate the logic in a UDF – so you could write a UDF that takes a
datetimeand returns adatetime, and expose that via the dbml onto the data-context. You can then use that in your queries:This approach, however, doesn’t necessarily make good use of indexes.
Update:
For the full gory details, you can look at
System.Data.Linq.SqlClient.PostBindDotNetConverter+Visitorin reflector – in particular theTranslate...methods; somestringfunctions are handled separately. So not a huge selection – but this is an implementation detail.