johnzabroski (1) [Avatar] Offline
#1
On Pg. 219, you write, "Not all CLR functions can be translated to a database equivalent. Consider the query:
var query =
from book in books where book.PubDate >= DateTime.Parse("1/1/2007"smilie <-- Works
select book.PubDate.Value.ToString("MM/dd/yyyy"smilie; <-- Fails
In this example, the translation provider is able to convert the DateTime.Parse method and insert a database-specific representation of the date. It is not able to handle the ToString method for formatting the data in the select clause. Identifying all of the supported and unsupported expressions that are translated is impossible."

Pardon my naivete, but why is it impossible. Whenever a programmer tells me something is impossible, I question whether they understand the theoretical requirements versus the requirements imposed by the current system they're using. My first suggestion is then to say, "How about augmenting the system to make this possible? What would such a system look like?"

Please, tell me what it looks like on a planet where this is possible. Where is the expressiveness of LINQ to SQL limited? Is it a fundamental flaw LINQ to SQL, fundamental flaw of LINQ, fundamental flaw of C#, or fundamental flaw of IL Assembly Language? Which of these systems is to blame for preventing me from doing something I innately want to do: map a C# method call to a Data Manipulation Language expression.

I realize your book may not be targeted for people like me, who think about these alternative design proposals and the follow-up issues, but where else can I go to discuss this? Typically, people like me figure it out for ourselves, and also don't contribute back the solution to others.