[CSHARP-4859] Support nested AsQueryable Created: 28/Nov/23  Updated: 28/Jan/24  Resolved: 28/Jan/24

Status: Closed
Project: C# Driver
Component/s: LINQ3
Affects Version/s: 2.22.0
Fix Version/s: 2.24.0

Type: New Feature Priority: Unknown
Reporter: Robert Stam Assignee: Robert Stam
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on CSHARP-4863 Refactor AggregateMethodToAggregation... Closed
is depended on by EF-63 Can't query on arrays of sub-documents In Code Review
Documented
Backwards Compatibility: Fully Compatible
Documentation Changes: Needed
Documentation Changes Summary:
  1. What would you like to communicate to the user about this feature?
    2. Would you like the user to see examples of the syntax and/or executable code and its output?
    3. Which versions of the driver/connector does this apply to?

Not sure whether to document this or not.

A human writing a LINQ query would normally never use a nested AsQueryable, which though legal is totally unnecessary and kind of silly. This feature was added to support the EF Core Provider.


 Description   

Consider supporting nested AsQueryable, for example:

collection.AsQueryable().Select(x => x.List.AsQueryable().Count()) 

and treat is as equivalent to:

collection.AsQueryable().Select(x => x.List.Count()) 

Using nested AsQueryable in this way doesn't make much sense, but it is legal C#.

The primary motivation for this change is to support the MongoDB EF Core Provider. Apparently EF Core inserts this call to AsQueryable and rewrites the expressions using the equivalent Queryable methods for each Enumerable method. Why it does this doesn't make much sense, but if we were to support this odd usage in the C# driver's LINQ provider it would make implementing the MongoDB EF Core Provider easier (otherwise the MongoDB EF Core Provider would have to undo what EF Core did to remove the unecessary AsQueryable).


Generated at Wed Feb 07 21:49:35 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.