Implement IQueryable instead of IOrderedQueryable in EntityQueryable, introduce OrderedEntityQueryable
- Dominant language
- C#
- Stars
- 14.8k
- Forks
- 3.4k
- PR merge metrics
- PR metrics pending
Description
DbSet returns the internal EntityQueryable, which implements IOrderedQueryable even though DbSets aren't ordered; since EF's LINQ provider always returns EntityQueryable, this is required in order to allow casting EntityQueryable to IOrderedQueryable when the OrderBy operator is called ([see the source code](https://github.com/dotnet/runtime/blob/main/src/libraries/System.Linq.Queryable/src/System/Linq/Queryable.cs#L751)). However, it means that checks whether the IQueryable returned from DbSet is ordered will return true, although it isn't (see #34363).
Instead, our implementation of CreateQuery() could check the return type of the method for the node being created, and return a different type (OrderedEntityQueryable) when that method returns IOrderedQueryable. This would align the runtime type we return with the static typing of the operators being composed. It would also add a runtime reflection check for each LINQ operator composition.
Overall I'm not sure this is important. Although in a very technical sense we're incorrect, the main point of IOrderedQueryable is for static typing (i.e. not allow ThenBy without a previous OrderBy), not for runtime checking. The proof is that we've had only a single complaint about this in EF's history (#34363), and even that complaint is mistaken (there's an expectation for Select to flow orderability, which it does not).
Contributor guide
Assessment
This issue has not been assessed yet.