Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AOT: support dynamically-generated queries #29760

Open
Tracked by #34446 ...
roji opened this issue Dec 4, 2022 · 1 comment
Open
Tracked by #34446 ...

AOT: support dynamically-generated queries #29760

roji opened this issue Dec 4, 2022 · 1 comment

Comments

@roji
Copy link
Member

roji commented Dec 4, 2022

Our initial work on precompiled queries (#25009) requires that queries be fully analyzable statically; that means the that entire LINQ query must be specified in one place - from the DbSet to the terminating operator which evaluates the query (e.g. ToList). In other words, it's impossible to precompile queries where LINQ operators are added dynamically.

The challenge with dynamic queries is that we don't know which materializers to pregenerate:

  • Any change in the query output (projection) requiers a different materializer. For example, different Includes require different materializers.
  • Other behavioral parameters change the materializer: split vs. single query, tracking/no tracking, buffering/no buffering.

It seems impractical to automatically pregenerate materializers for each and every one of the above options. Instead, we'd likely need to provide some sort of way for the user to tell us which materializers are actually needed. For example, they may use an API which contains a static version of the query, but projecting out the structure that their dynamic one would produce. At AOT-time, we'd recognize this and generate the appropriate materializer. At runtime, the query pipeline (1st part) would still fully run, but at the end would pick up out precompiled materializer instead of generating it.

This also implies annotating the entire query pipeline for AOT/trimming, which may be quite a tricky problem in itself.

@AndriySvyryd
Copy link
Member

We could also make a single materializer itself handle different scenarios, see #32923. This should be enough to handle non-anonymous types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants