Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Suppose I have a LINQ to SQL (or EntityFramework) data context (object context). I want to query some data from it and sort the result set. The query would look like:
using(var dc = new TestDataContext) // = new TestEntities)
{
var query = dc.MyEntities.Where(e => /*my where clause*/)
.OrderBy(/*my sorting field*/)
.ThenBy(/*another sorting field*/);
foreach(var entity in query)
{
//...
}
}
Depending on the type of an argument different OrderBy and ThenBy methods may be used.
Queryable.OrderBy Method with Expression<Func<TSource, TKey>>
Enumerable.OrderBy Method with Func<TSource, TKey>
In DataContext.Log one can see that Queryable.OrderBy compiles the given expression into the SQL statement executed over the database, while when using Enumerable.OrderBy LINQ actually does the sorting over the objects in the programm's memory, i.e. the query over the database is executed without sorting...
What are other possible peculiarities, I may come across?
This question arised after this: SO How to make expression treat value type as a reference type?
In DataContext.Log one can see that Queryable.OrderBy compiles the
given expression into the SQL statement executed over the database,
while when using Enumerable.OrderBy LINQ actually does the sorting
over the objects in the programm's memory,
That's the only difference. And because compiler can translate your lambda Func<T> into Expression<Func<T>> the Queryable.OrderBy will be used by default.
When a lambda expression is assigned to a variable, field, or parameter whose type is Expression<TDelegate>, the compiler emits instructions to build an expression tree.
from Expression<TDelegate> Class
If you really need to perform LINQ to Objects Enumerable.OrderBy call AsEnumerable() before OrderBy call.
The difference here is that persistence frameworks such as NHibernate and Entity Framework have their own LINQ providers that traverse expression trees and build SQL queries. This is thanks to deferred execution. Nothing actually happens with an IQueryable until something forces the provider to evaluate it.
On the other hand.. LINQ can do in-memory queries AFTER the above has taken place. Maybe this will make more sense:
var result = db.Entities.Table
.Where(x => x.Id == 1) // SQL WHERE clause
.OrderBy(x => x.Id) // SQL ORDER BY clause
.ToList() // Query the database and store result
.Sum(x => x.SomethingElse) // Sum the field in memory
.ToList(); // convert back to a list.
As you can see.. halfway through that chain the provider hits the database with a generated query. The ToList() call forces the provider to query the database for results. After that, it's all in-memory.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 17 days ago.
Improve this question
Is there a way to translate predicate(Func<T,bool>) using LINQ to SQL query or something similar to this?
Found nothing on internet or MS guides.
ORMs (like Entity Framework, linq2db, and others) in C# usually use expression trees and IQueryable to be able to translate the code into actual SQL queries, so they need Expression<Func<T, bool>>, not just Func<T, bool>. If you are creating the predicate via lambda then compiler can also translate it to expression tree, i.e.:
Func<MyClass, bool> predicate = mc => mc.IntProp == 1;
Exppression<Func<MyClass, bool>> predicate = mc => mc.IntProp == 1;
Will work both well. So in some cases you can just change your method parameter and that's it.
Read more:
Expression Trees
What is the difference between IQueryable and IEnumerable?
LINQKit - interesting library which does some magic around LINQ
Short awnser : no
Long awnser : yes... but actually no
There is no way to accuratly translate a programming language into another without the risk of the function and meaning being altered
(you could use this but even that is no longer mantained)
I would recommend you learning LinQ in order to safely translate it without mistakes.
You could also post you query so anyone like me or other more fitted members to help you out in the translation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
EDIT
Actually this question should be more general: How to modify query to DB if Linq with IQueryable gives errors?
The correct answer is as far as I understand — to get as much of the query done at the database level. Because in this particular case my complicate query just can not be transform from Linq to sql.
So I just wrote a raw sql query with FromSqlRaw() method and errors have gone. Moreover I wrote query in the way that does not take all entries (with filtering) as opposed to ToList() method, so I have less doubt about performance (though I did not measure it).
Need some help with understanding how to use linq with converting List to IQueryable.
What I had:
A three tables in DB with IQueryable-based queries to one of them.
What I need:
To create a query that combine data from three tables by Linq and give me resulting specific column with data for every element of one of table with function of filtering by this column.
What I try:
Supplement IQueryable-based query. But I found problems with List to IQueryable converting. Method AsQueryable() gives errors.
What I achieve:
I rewrite queries with List-based logic in Linq and it gives me what I need. But I do not understand:
Is this practice good?
Why should I often must make ToList() conversion for avoiding errors?
Is the speed of my solution worse than IQueryable-based approach?
Here is fiddle with my exercises: https://dotnetfiddle.net/BAKi6r
What I need I get in listF var.
I totally replace CreateAsync method in it with Create method for List. Is it good?
I also try to use hardcoded Lists with CreateAsync method /items2moq, items3moq/, but they with filtered List-based query give The provider for the source IQueryable doesn't implement IAsyncQueryProvider error. Also I got Argument types do not match error when I use IQueryable for NamesIQ instead of List for NamesList. What exactly the source of this errors?
Why should I often must make ToList() conversion for avoiding errors?
I often think about Linq queries in three "levels":
IQueryable - there are designed to translate a Linq query into an equivalent database (or whatever data source you're using) query. Many Linq and non-Linq operations just can't be translated into its SQL or other equivalent, so this layer would throw an error. Even operations that seem simple (like splitting a string) are difficult if not impossible to do in SQL
IEnumerable - in this layer, Linq queries are done in memory, so there's much more flexibility to do custom operations. To get from the IQueryable layer to the IEnumerable layer, the AsEnumerable() call is the most straightforward. That separates the part of the query that gets raw data from the part that can create custom objects, do more complex filtering and aggregations, etc. Note that IEnumerable still uses "deferred execution", meaning that at this stage, the query is just a query - the results don;t actually get computed until you enumerate it, either with a foreach loop or by advancing to the next layer:
List/Array/etc. This is where queries are executed and turned into concrete collections. Some of the benefits of this layer are serializability (you can't "serialize" an enumerator) and eager-loading (as opposed to deferred execution described above).
So you're probably getting an error because you have some part of your query that can't be translated by the underlying Queryable provider, and using ToList is a convenient way to materialize the raw data into a list, which allows you to do more complex operations. Note that AsEnumerable() would do the same thing but would maintain deferred execution.
Is this practice good?
It can be, but you might easily be getting more data than you need by doing filtering at the list level rather than at the database level. My general practice is to get as much of the query done at the database level, and only moving to the enumerable/list level when there's no known way to translate the rest of the query to SQL.
Is the speed of my solution worse than IQueryable-based approach?
The only way to know is to try it both ways and measure the difference. But it's a pretty safe bet that if you get more raw data than you need and filter in memory that you'll have worse performance.
This question already has answers here:
LINQ to Entities does not recognize the method Int32 get_Item(Int32)
(3 answers)
Closed 5 years ago.
I'm trying to get the price from database with linq query but this exception apperas constantly, I dont know why.
The data types are the same, both decimals.
newOrder.Cmimi = Convert.ToDecimal(context.Produktets.Where(c=>c.Emri_Produktit == prodName[0]).Select(c => c.Cmimi).First());
Can someone help please ?????
Looks like you are using array indexer in a linq query and linq to entities is failing to translate prodName[0] into SQL. You can try to store the value in a variable and use it in the query instead:
var name = prodName[0];
newOrder.Cmimi = Convert.ToDecimal(context.Produktets
.Where(c => c.Emri_Produktit == name)
.Select(c => c.Cmimi).First());
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Written on msdn:
Returns the input typed as IEnumerable<T>.
I do not understand.
Help me to understand this method.
There are three implementations of AsEnumerable.
DataTableExtensions.AsEnumerable
Extends a DataTable to give it an IEnumerable interface so you can use Linq against the DataTable.
Enumerable.AsEnumerable<TSource> and ParallelEnumerable.AsEnumerable<TSource>
The AsEnumerable<TSource>(IEnumerable<TSource>) method has no effect
other than to change the compile-time type of source from a type that
implements IEnumerable<T> to IEnumerable<T> itself.
AsEnumerable<TSource>(IEnumerable<TSource>) can be used to choose
between query implementations when a sequence implements
IEnumerable<T> but also has a different set of public query methods
available. For example, given a generic class Table that implements
IEnumerable<T> and has its own methods such as Where, Select, and
SelectMany, a call to Where would invoke the public Where method of
Table. A Table type that represents a database table could have a
Where method that takes the predicate argument as an expression tree
and converts the tree to SQL for remote execution. If remote execution
is not desired, for example because the predicate invokes a local
method, the AsEnumerable<TSource> method can be used to hide the
custom methods and instead make the standard query operators
available.
In other words.
If I have an
IQueryable<X> sequence = ...;
from a Linq Provider, like Entity Framework, and I do,
sequence.Where(x => SomeUnusualPredicate(x));
that query will be composed on and run on the server. This will fail at runtime because Entity Framework doesn't know how to convert SomeUnusualPredicate into SQL.
If I want that to run the statement with Linq to Objects instead, I do,
sequence.AsEnumerable().Where(x => SomeUnusualPredicate(x));
now the server will return all the data and the Enumerable.Where from Linq to Objects will be used instead of the Query Provider's implementation.
It won't matter that Entity Framework doesn't know how to interpret SomeUnusualPredicate, my function will be used directly. (However, this may be an inefficient approach since all rows will be returned from the server.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Does anyone stick to any rules (or are you forced to stick to any rules by your employer?) when choosing to use either LINQ query syntax or a Lambda expression inside one of the LINQ extension methods? This applies to any Entities, SQL, objects, anything.
At our workplace, my boss doesn't like lambda at all and he'd use the query syntax for anything, which in some cases, I find are less readable.
var names = collection.Select(item => item.Name);
var names = from item in collection
select item.Name;
Maybe when adding a condition, the Lambda I find gets a little messy, where the
var names = collection.Where(item => item.Name == "Fred")
.Select(item => item.Name);
var names = from item in collection
where item.Name == "Fred"
select item.Name;
Just out of interest: how does the compiler treat this one? Does anyone know how the above LINQ query will compile into lambda? Will the Name property be called for each element? Could we do this instead and potentially improve the performance? Would this mean lambda is slightly more controllable in terms of performance?
var names = collection.Select(item => item.Name)
.Where(name => name == "Fred");
Certainly when we start using more and more expressions, the lambda gets messy and I'd start to use the query syntax here.
var names = collection.Where(item => item.Name == "Fred")
.OrderBy(item => item.Age)
.Select(item => item.Name);
var names = from item in collection
where item.Name == "Fred"
order by item.Age
select item.Name;
There are also a few things that I find can't be done with the query syntax. Some of them you'd think would be really simple (particularly aggregate functions), but no, you have to add one of the LINQ extension methods to the end, which imo, look neater with a lambda expression.
var names = collection.Count(item => item.Name == "Fred");
var names = (from item in collection
where item.Name == "Fred"
select item).Count()
Even for some of the simple lambda chains, ReSharper is suggesting I convert them to LINQ querys.
Can anyone else add to this? Does anyone have their own little rules or does their company suggest/force the use of one?
To answer your question about translation, the query expression will always be translated based on the rules on 7.16 of the C# 4 spec (or the equivalent in the C# 3 spec). In the example where you're asking the question about the Name property, that's not a matter of the query expression translation - it's what the Select and Where methods do with the delegates or expression trees they take as parameters. Sometimes it makes sense to do a projection before filtering, sometimes not.
As for little rules, I only have one: use whichever way is most readable for the query in question. So if the query changes and "which form is more readable" changes at the same time, change the syntax used.
If you're going to use LINQ you should be happy with either syntax, at the very least to read.
I tend to find that queries with multiple range variable (e.g. via SelectMany or Join, or a let clause) end up being more readable using query expressions - but that's far from a hard and fast rule.