Support parameterized and inline lists of complex types in queries
- Dominant language
- C#
- Stars
- 14.8k
- Forks
- 3.4k
- PR merge metrics
- PR metrics pending
Description
This tracks the following:
```c#
Tag[] tags = [...];
// Contains:
var tagIds = await context.Blogs
.Where(b => tags.Contains(b.Tag))
.ToListAsync();
// Arbitrary LINQ operators:
var tagIds = await context.Blogs
.Where(b => tags.Intersect(b.Tags).Count() == 2)
.ToListAsync();
// Similarly for inline collections:
var tagIds = await context.Tags
.Where(t => new Tag[] { ... }.Contains(t))
.ToListAsync();
// Possibly problematic:
var tagIds = await context.Blogs
.Where(b => tags.Where(t => t.Name == b.Foo && t.Size == t.Bar)
.ToListAsync();
// Here each field on the unknown Tag type gets its type mapping inferred separately based on what it's compared to; we do this for primitive collections but for just one scalar rather than multiple.
```
This is very similar to what we already support with scalar collections - but with complex types. We'd need to decide on the parameter representation: at least in theory the 3 translation modes we currently support for scalar collections could be applicable (Parameter, Constants, MultipleParameters). For inline collections, this would mean ValueExpression with more than one (data) column.
The main difficulty here is that our query pipeline currently doesn't support representing a projection of an unknown .NET type (only modeled entity/complex types or scalars); where the above requires at least a temporary representation where a Tag CLR type is being projected without it being related to the modeled Tag type.
Note #11799 which is about tuples, as opposed to mapped complex types as here.
Contributor guide
Assessment
This issue has not been assessed yet.