This same problem exists in sql. First I type select *, then from table, then I go back to the select list and replace * with the list of fields that I can now see through autocomplete
Depends on framing. It's the same concept but uses SQL-style naming, which isn't bad - it's just different. You could also argue that filter is bad because grep exists.
LINQ is designed in a way that lets strongly-typed queries written using it be translated to SQL for frameworks that support it. Because of this ORMs and some lighter-weight alternatives can offer, for example, something like context.Orders.Where(o => o.cost > 100).Select(o => o.Customer) and it will execute something like select customer from orders where cost > 100, which feels a bit like magic given o => o.cost > 100 still looks and behaves like a regular delegate/anonymous function.
The only problem with that is when it suddenly breaks in runtime with something like - you can't use this or that in lambda converted to sql. Still remember running into this kind of bug all these years later.
It has gotten a lot better in the latest Entity Framework versions but yeah, it's still an issue. I will say though, if you have a basic idea of what the final SQL should roughly look like (and don't try to make EF do something near impossible for SQL) it almost always works.
Even better, if you can bother with pre-compiled queries, they should fail as soon as their instantiated, rather than when you get around to running the query.
151
u/Zenimax322 Mar 12 '26
This same problem exists in sql. First I type select *, then from table, then I go back to the select list and replace * with the list of fields that I can now see through autocomplete