How do I make an EF-Core (2.1) Compiled Query return an IQueryable?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I've been trying to convert a query that gets executed a lot in my application to a compiled query, with no success. I've boiled it down to a simple query so have concluded that I must be misunderstanding how something works.
Here is the simple example query without using compile query (this works):
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
(Entities context) =>
from au in context.Users select au;
Once I add the compile query call:
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
EF.CompileQuery((Entities context) =>
from au in context.Users select au);
I get this exception:
Cannot implicitly convert type 'System.Func>' to 'System.Func>'. An explicit conversion exists (are you missing a cast?)
For the life of me, I can't figure out what I'm doing wrong...any suggestions?
linq iqueryable ef-core-2.1
add a comment |
I've been trying to convert a query that gets executed a lot in my application to a compiled query, with no success. I've boiled it down to a simple query so have concluded that I must be misunderstanding how something works.
Here is the simple example query without using compile query (this works):
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
(Entities context) =>
from au in context.Users select au;
Once I add the compile query call:
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
EF.CompileQuery((Entities context) =>
from au in context.Users select au);
I get this exception:
Cannot implicitly convert type 'System.Func>' to 'System.Func>'. An explicit conversion exists (are you missing a cast?)
For the life of me, I can't figure out what I'm doing wrong...any suggestions?
linq iqueryable ef-core-2.1
Compiling means creating the SQL query and reusing it. Applying more LINQ operators to that query would mean recompiling it.
– Panagiotis Kanavos
Nov 26 '18 at 16:50
add a comment |
I've been trying to convert a query that gets executed a lot in my application to a compiled query, with no success. I've boiled it down to a simple query so have concluded that I must be misunderstanding how something works.
Here is the simple example query without using compile query (this works):
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
(Entities context) =>
from au in context.Users select au;
Once I add the compile query call:
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
EF.CompileQuery((Entities context) =>
from au in context.Users select au);
I get this exception:
Cannot implicitly convert type 'System.Func>' to 'System.Func>'. An explicit conversion exists (are you missing a cast?)
For the life of me, I can't figure out what I'm doing wrong...any suggestions?
linq iqueryable ef-core-2.1
I've been trying to convert a query that gets executed a lot in my application to a compiled query, with no success. I've boiled it down to a simple query so have concluded that I must be misunderstanding how something works.
Here is the simple example query without using compile query (this works):
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
(Entities context) =>
from au in context.Users select au;
Once I add the compile query call:
private static Func<Entities, int, string, IQueryable<Users>> _getUsers =
EF.CompileQuery((Entities context) =>
from au in context.Users select au);
I get this exception:
Cannot implicitly convert type 'System.Func>' to 'System.Func>'. An explicit conversion exists (are you missing a cast?)
For the life of me, I can't figure out what I'm doing wrong...any suggestions?
linq iqueryable ef-core-2.1
linq iqueryable ef-core-2.1
edited Nov 26 '18 at 17:00
marc_s
584k13011241270
584k13011241270
asked Nov 26 '18 at 15:36
jceddyjceddy
3651211
3651211
Compiling means creating the SQL query and reusing it. Applying more LINQ operators to that query would mean recompiling it.
– Panagiotis Kanavos
Nov 26 '18 at 16:50
add a comment |
Compiling means creating the SQL query and reusing it. Applying more LINQ operators to that query would mean recompiling it.
– Panagiotis Kanavos
Nov 26 '18 at 16:50
Compiling means creating the SQL query and reusing it. Applying more LINQ operators to that query would mean recompiling it.
– Panagiotis Kanavos
Nov 26 '18 at 16:50
Compiling means creating the SQL query and reusing it. Applying more LINQ operators to that query would mean recompiling it.
– Panagiotis Kanavos
Nov 26 '18 at 16:50
add a comment |
1 Answer
1
active
oldest
votes
How do I make an EF-Core (2.1) Compiled Query return an IQueryable?
You can't. All EF.Compile
methods return either IEnumerable<TResult>
or TResult
, and the corresponding Async
methods return respectively AsyncEnumerable<TResult>
or Task<TResult>
.
As you can see, there no IQueryable<T>
returning methods. In other words, the compiled queries are supposed to be final (non composable) - the overloads allow you to pass the necessary arguments.
I can't say exactly why is that. The explanation for the Explicitly Compiled Queries in the EF Core documentation is:
Although in general EF Core can automatically compile and cache queries based on a hashed representation of the query expressions, this mechanism can be used to obtain a small performance gain by bypassing the computation of the hash and the cache lookup, allowing the application to use an already compiled query through the invocation of a delegate.
Looks like the idea is to not only cache the IQueryable
expression tree, but also skip the transformation of the expression tree to whatever data structure they use internally.
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
1
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
1
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53484492%2fhow-do-i-make-an-ef-core-2-1-compiled-query-return-an-iqueryable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
How do I make an EF-Core (2.1) Compiled Query return an IQueryable?
You can't. All EF.Compile
methods return either IEnumerable<TResult>
or TResult
, and the corresponding Async
methods return respectively AsyncEnumerable<TResult>
or Task<TResult>
.
As you can see, there no IQueryable<T>
returning methods. In other words, the compiled queries are supposed to be final (non composable) - the overloads allow you to pass the necessary arguments.
I can't say exactly why is that. The explanation for the Explicitly Compiled Queries in the EF Core documentation is:
Although in general EF Core can automatically compile and cache queries based on a hashed representation of the query expressions, this mechanism can be used to obtain a small performance gain by bypassing the computation of the hash and the cache lookup, allowing the application to use an already compiled query through the invocation of a delegate.
Looks like the idea is to not only cache the IQueryable
expression tree, but also skip the transformation of the expression tree to whatever data structure they use internally.
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
1
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
1
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
add a comment |
How do I make an EF-Core (2.1) Compiled Query return an IQueryable?
You can't. All EF.Compile
methods return either IEnumerable<TResult>
or TResult
, and the corresponding Async
methods return respectively AsyncEnumerable<TResult>
or Task<TResult>
.
As you can see, there no IQueryable<T>
returning methods. In other words, the compiled queries are supposed to be final (non composable) - the overloads allow you to pass the necessary arguments.
I can't say exactly why is that. The explanation for the Explicitly Compiled Queries in the EF Core documentation is:
Although in general EF Core can automatically compile and cache queries based on a hashed representation of the query expressions, this mechanism can be used to obtain a small performance gain by bypassing the computation of the hash and the cache lookup, allowing the application to use an already compiled query through the invocation of a delegate.
Looks like the idea is to not only cache the IQueryable
expression tree, but also skip the transformation of the expression tree to whatever data structure they use internally.
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
1
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
1
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
add a comment |
How do I make an EF-Core (2.1) Compiled Query return an IQueryable?
You can't. All EF.Compile
methods return either IEnumerable<TResult>
or TResult
, and the corresponding Async
methods return respectively AsyncEnumerable<TResult>
or Task<TResult>
.
As you can see, there no IQueryable<T>
returning methods. In other words, the compiled queries are supposed to be final (non composable) - the overloads allow you to pass the necessary arguments.
I can't say exactly why is that. The explanation for the Explicitly Compiled Queries in the EF Core documentation is:
Although in general EF Core can automatically compile and cache queries based on a hashed representation of the query expressions, this mechanism can be used to obtain a small performance gain by bypassing the computation of the hash and the cache lookup, allowing the application to use an already compiled query through the invocation of a delegate.
Looks like the idea is to not only cache the IQueryable
expression tree, but also skip the transformation of the expression tree to whatever data structure they use internally.
How do I make an EF-Core (2.1) Compiled Query return an IQueryable?
You can't. All EF.Compile
methods return either IEnumerable<TResult>
or TResult
, and the corresponding Async
methods return respectively AsyncEnumerable<TResult>
or Task<TResult>
.
As you can see, there no IQueryable<T>
returning methods. In other words, the compiled queries are supposed to be final (non composable) - the overloads allow you to pass the necessary arguments.
I can't say exactly why is that. The explanation for the Explicitly Compiled Queries in the EF Core documentation is:
Although in general EF Core can automatically compile and cache queries based on a hashed representation of the query expressions, this mechanism can be used to obtain a small performance gain by bypassing the computation of the hash and the cache lookup, allowing the application to use an already compiled query through the invocation of a delegate.
Looks like the idea is to not only cache the IQueryable
expression tree, but also skip the transformation of the expression tree to whatever data structure they use internally.
answered Nov 26 '18 at 16:42
Ivan StoevIvan Stoev
109k788144
109k788144
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
1
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
1
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
add a comment |
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
1
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
1
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
I'd say this makes sense. EF Core's compilation step produces SQL. Once you have that SQL statement you can't apply more Queryable operators to it without having to recompile the result into SQL.
– Panagiotis Kanavos
Nov 26 '18 at 16:49
1
1
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
@PanagiotisKanavos I'm not quite sure it's SQL, especially taking into account the client/mixed evaluation. But for sure is some AST or similar structure specific for the execution of the query.
– Ivan Stoev
Nov 26 '18 at 16:58
1
1
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
Thanks. I was confused because I saw an example that had IQueryable as the return value.
– jceddy
Nov 26 '18 at 20:58
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
@jceddy did you get any benefit by doing this? There are a lot of discussions on this over the internet. So it confuses me a little. Though for some cases it executes faster than without external compilation and in some cases it is slower.
– sina_Islam
Jan 18 at 16:50
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53484492%2fhow-do-i-make-an-ef-core-2-1-compiled-query-return-an-iqueryable%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Compiling means creating the SQL query and reusing it. Applying more LINQ operators to that query would mean recompiling it.
– Panagiotis Kanavos
Nov 26 '18 at 16:50