> Though EF generally can't detect all possible patterns and optimize everything for you; using an ORM doesn't mean you can forget about perf and not examine your queries.
No shit
I'm sure adding an extra magic lambda would fix it tho
@PaulWhite I actually like this statement, the obviousness is good for developers who know not much about the database side and the subgroup of them who think it's easy because they never wrote more than a simple SELECT statement. EF / ORMs take an object-oriented approach to help automate the database side for you, and when a team at a company like Microsoft admits it's not perfect, it helps show the complexity of the database side IMO.
That's not to take away from the fact that the EF team does do some questionable things, and there are obvious improvements that can be made to the framework though.
Especially with the possibility of living in a simulation like the matrix.
Fun fact, the more edits you see me make on one of my answers, the more asleep I was when I thought I knew what I was talking about when I originally wrote it.
Well it's ironic too... I just caught up on that Twitter thread. And your point: "Point was people will write code like the example" alone is funny because the EF Team could've just used a better example in their screenshot, and avoided being called out on this one. The irony is Shay's reply admits this "You can easily get the query to use an index by writing your LINQ query with...".
Hahaha. I was hoping what you quoted was at least a reply from someone on the EF team when I wrote the reply, otherwise I'd just be talking out my ass which tends to happen when not enough 💤
I thought the whole point of EF was that you wouldn’t have to examine the queries you don’t know how to write because you’re using EF to generate queries
@ErikDarling Yea and Paul may be right, that EF should've stuck to only generating SQL for simple queries, let the rest of them be sorted out on the client side instead. Or more so if they spent more depth on making a couple of specific generated query situations better in each iteration, instead of a breadth approach of doing it all not so well, they might've been better off.
Right, they stuff like “it’s perfect for 90% of simple crud apps” but 90% of simple crud apps don’t need all the bells and whistles and lambdas that they glue in
Even worse is that these advanced features are written in by people who don’t seem to have practical database experience
@ErikDarling Yea that's been my biggest gripe. Going back to that weird ROW_NUMBER() in an ORDER BY clause to "fix" a nondeterministic sorting problem in EF 6. Like anyone from the database team at Microsoft could've taught them why that doesn't actually work easily. I really don't think the two teams communicate.
I thought the whole point of EF was that you wouldn’t have to examine the queries you don’t know how to write because you’re using EF to generate queries
Also, just been reading some of the open issues for async and Microsoft.Data.SqlClient. There are some real problems there.
> While high-level layers and O/RMs such as EF Core considerably simplify application development and improve maintainability, they can sometimes be opaque, hiding performance-critical internal details such as the SQL being executed.
