Query: Use of types that are neither entities nor anonymous inside a query triggers client-side evaluation

[divega]

For a query that internally projects into an range variable of a type which is not recognized as either an entity type or an anonymous type, any subsequent query operators is evaluated in memory even if the range variable is not present in the final projection.

In theory we could recognize more common cases in which intermediary types can be eliminated from the query. This can improve how we process queries with nominal types that are not anonymous types (e.g. DTOs), property bags, tuples, etc.

In some of those cases we would need to have knowledge of specific getter and setter patterns to be able to correlate different RHS and LHS expressions representing the same members.

cc @anpete

[smitpatel]

@divega - Can you post an example query here?

[divega]

@smitpatel I haven't tested any specific query with this problem but based on the conversation with @anpete that made me to file the issue, I believe something like this should do:

var cs = db.Customers
    .Select(c => new CustomerDto {Id = c.Id, Name = c.Name})
    .OrderBy(dto => dto.Name)
    .ToList();

The query could use a tuple or a dictionary instead of CustomerDto, or initialize it using a constructor, or have fields instead of properties. There is a spectrum of patterns we could recognize, regular class with properties being likely the most common.

[smitpatel]

The above posted query should work. #8198 Implemented code for it. (also added test similar to above). Basically at this stage we support, object initialization syntax.
Initialization through a constructor may be incorrect to translate as we don't know what processing constructor does. (like what is constructor is adding +1000 to id column)
I am not sure what is pattern in which fields can be used instead of properties.

Tuple/Dictionary are not recognized perhaps rare patterns. Which caused us to use AnonymousObject for new IncludeCompiler

[divega]

Good to know that we support object initializers beyond anonymous types already. This issue is then about everything else that is possible and it is fine for it to remain in the backlog. You are right that the constructor thing requires some trust and would only "be correct" (i.e. work the same regardless of where it is evaluated) work if the object definition follows certain convention. Incidentally we would have similar requirements to work with constructors and factories for materialization.

[smitpatel]

Consider scenario in #12728