I hadn’t noticed this before.
If you have a stored procedure that is mapped to an entity such as "GetCustomersSince" which returns Customer entities, the command is executed when you create the query, not, like with normal queries, when the data is first needed.
In case that sentence was too convoluted…
Here is a LINQ to Entities query (the same is true for LINQ to anything and also for Object Services (context.CreateQuery))
Dim query= From c In context.Customers Select c
For Each cust in Query <– command is executed here
‘do something
End For
But when calling a function import:
dim custs= From c in context.GetCustomersSince(New Date("2008","01","01")) <–command is executed here
For Each cust in custs
‘do something
End For
Looking at the code gen for the function I can see that ObjectContext.ExecuteFunction is called.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
This is what makes deffered execution in LINQ and the different flavors so confusing for people to get. It’s not consistent and really only work for straight forward from … in .. select queries. That’s one of the reasons why I always recommend my customers to be explicit with the execution, it is the one thing about the execution you can affect, and make your code more explicit. Another reasons are that you want to know /when/ you hit the database, you want to control that. It shouldn’t happen by accident. I usually make it a habit to make sure that when I’ve left the layer responisble for the query, the repository for my default design, the database won’t be bothered anymore and I will know this.Waiting for your book Julie, when are you getting it out 😉