Add Support for custom Extension methods
Support extension methods to be defined for entities or generic extensions. As long as the extension returns an IQueryable or expression that only includes supported operations/extensions, then the provider should expand the extension method and replace it in the expression tree with the the returned iqueryable/expression.
Thus for the most part, any extension method encountered in the expression that is not supported, should be called to return an expression that can be inserted into the expression tree. So long as the process operators recursively as it is expanding the expression, eventually the expression tree will consist of supported expressions and from there the existing expression translator can be used.
An example of such a visitor is here:
There are some problems with this implementation though. For example the requirement to use AsExpandable and AsQueryable to ensure the IQueryable version and not Ineumerable version is called. Where as supported extension methods like .Where do not require you to call .AsQueryable first, and the runtime automatically understands that it should not use the IEnumerable extension method because it is being translated into an expression. All attempts I have made to determine how this "magic" occurs for supported extensions, so that I could implement similar magic for custom extensions, has lead to dead ends or someone telling me it is a mysterious "implementation detail".
Now that EF is open sources though, perhaps I will be able to investigate this further.
Reset status to reflect state in EF Core.
This was contributed to EF 6.1.2 by BrandonDahler in this PR: http://entityframework.codeplex.com/SourceControl/network/forks/BrandonDahler/EntityFramework/contribution/7352
Hello, this suggestion seems to combine a few interesting ideas to extend LINQ to Entities: provider specific extensions, expandable expression methods and client side evaluation. It would be worth discussing and elaborating the details a little more.
I would like to encourage you to start a discussion on our codeplex site.
Regarding the supposed "magic" that let us process extension methods such as Where regardless on whether they are the version defined for IQueryable<T> or IEnumerable<T>, we rely completely on the compiler. The only time LINQ to entities sees the IEnumerable version is if it got captured by the compiler in a nested expression, i.e. it wasn't executed.
I want to emphasize that ideally it would operate recursively, so that only the leaf extension method calls need contain supported expressions. Intermediate extension methods could utilize other extension methods and so on, so long as at the end of expanding all of the unsupported expressions, the expression tree contains only supported expressions. This would be the ideal scenario for code reuse and abstracting reusable queries.