Make change tracking and the update pipeline compatible with AOT/trimming

[roji]

Note that although ExecuteUpdate/Delete allow bypassing change tracking and the update pipeline, we have no ExecuteInsert.

[kant2002]

Explanation of this thing a bit unclear. I read title as that some internal work for making code trimmable is needed. But in the description it sounds like introduction of ExecuteInsert which can bypass change tracking and update pipeline will do the trick. I'm just looking for easy NativeAOT related work in this repo, so curious is this task can be interpreted as such?

[roji]

@kant2002 the note above was only meant to say we have the query-based update and delete APIs (ExecuteUpdate/Delete) which bypass change tracking and the update pipeline, so the ongoing work to make the query pipeline compatible with NativeAOT would also make it possible to update and delete, even if change tracking and the update pipeline aren't compatible. However, EF still does not allow insertion without going through change tracking and the update pipeline (#29897 tracks adding that), so making change tracking and the update pipeline trimming/AOT-compatible is necessary.

As always, you're welcome to look at doing NativeAOT comaptibility work for these components; but I'm afraid that wouldn't be "easy" work for anyone not familiar with EF internals. If you do want to dive in, it would be good to post a quick plan detailing what you intend to do, so we can agree on the approach before you spend too much time on implementation etc.
Unfortunately, I'm not sure there's "easy" NativeAOT work

[kant2002]

I understand that I cannot just land on codebase such EF Core and "just do NativeAOT", some amount of struggle is expected. But I still prefer finding place which is easier, since that allow me work on more or less self-sufficient manner.

I think most important question regarding NativeAOT/trimming work is how do you plan to test changes?

• Is there already some test infrastructure for that, or something should be added?
• Should this test infra to be created first before some work should be done?
• Is this something outsider can help with? Maybe the plan is just to enable PublishTrimming/PublishAot somewhere and that's it.
• is there set of specific scenarios/tests which should pass in NativeAOT/trimming worlds so this can be considered done?

This is generic questions, so maybe they should be in parent issue, don't know.

[roji]

@kant2002 are you asking about how NativeAOT/trimming test infra works in general (outside of EF)? Or about the EF approach to testing NativeAOT/trimming? At the moment there's almost nothing in place (except for an extremely minimal trimming console app which provides only very basic coverage).

The exact scope of EF compatibility with NativeAOT/trimming (and therefore, what is covered by testing) will probably become apparent as the work progresses. In an ideal world, we'd be able to use the existing EF test suite, and simply run it with NativeAOT publishing; that would leverage the extremely comprehensive test coverage which EF already has, rather than starting from scratch. Unfortunately, there are likely to be various hurdles there, with xUnit NativeAOT compatibility possibly being one.

So I'm not quite sure how to answer your questions.. I'm hard at work at the moment on #25009 - precompiled queries - which are pretty much a prerequisite to NativeAOT support. Testing is something I intend to think about later in the process.

[roji]

@AndriySvyryd should we keep this open to track getting to zero warnings for change tracking/update pipelin?

[AndriySvyryd]

At this point I think it would be more appropriate to have an overall issue to drive warnings to 0

[roji]

OK, opened #33478. Note that there's already #29759 tracking getting to zero warnings for the 2nd part of the query pipeline, which presumably would be more on my plate - so maybe good to keep those two issues apart (though we can do whatever).