Stop using materializer expression in query

[AndriySvyryd]

Instead use the metarializer Func that can be part of the compiled model.

This would require refactoring to make the materializer compatible with any combination of Includes

[roji]

@AndriySvyryd just to note that the variability of materializers goes beyond just the different combinations of Includes - there's tracking/no-tracking, split vs. single query, etc. etc. All these combinations produce fundamentally different materializers, and creating a "generic" materializer that can handle all/most cases seems like it would start moving in a direction which puts into question code generation in the first place...

Of course, we could also pre-generate materializers for the various permutations (a bit like we want to pre-generate SQLs for various parameter nullness combinations), but I'm not sure we want to go in this direction either...

[roji]

After an offline conversation, I understand that the above refers to the more narrow materializer (i.e. instantiate an entity CLR type based on values from DbDataReader) rather than to the whole shaper (which contains/drives the materializers), so then stuff like tracking/no-tracking or split/single indeed aren't relevant there.

[roji]

I've also opened #34445, which is about reusing shapers (not materializers) across queries - both that and this can be implemented.

@AndriySvyryd am wondering what's the advantage of doing materializer generation in the compiled model, as opposed to generating it in the query pipeline as today, but implementing caching for reuse... I can see the following advantages in keeping this in query:

• People get reuse even if they don't use the compiled model
• We have future features which may affect materialization generation across queries (e.g. partial loading), so it may be more future-proof to keep this as part of query. In other words, if we do the caching right we can still reuse customized materializers in query, but doing this in the compiled model would mean pregenerating all permutations, which doesn't work.
• (Somewhat contrived) We don't generate materializers for entity types that are never actually loaded (e.g. because they're always projected out to something else).

[AndriySvyryd]

@AndriySvyryd am wondering what's the advantage of doing materializer generation in the compiled model, as opposed to generating it in the query pipeline as today, but implementing caching for reuse...

It doesn't have to be in the compiled model, it could be generated by the precompiled queries. The important part is that it shouldn't be inlined if it's used in more than one query.

[roji]

Agreed.