Open AndriySvyryd opened 3 months ago
@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...
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.
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