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

Nav expansion does not handle ExecuteUpdate #32493

Open
roji opened this issue Dec 2, 2023 · 1 comment
Open

Nav expansion does not handle ExecuteUpdate #32493

roji opened this issue Dec 2, 2023 · 1 comment

Comments

@roji
Copy link
Member

roji commented Dec 2, 2023

An EFCore.PG 8.0 regression was flagged (npgsql/efcore.pg#3001), which happened because the ExecuteUpdate value selector lambda does not get visited inside nav expansion. This means, for example, that updates such as the following cannot be translated:

  await db.Test
    .Where(x => x.TextParts.Concat(arr).Count() == 8)
    .ExecuteUpdateAsync(c => c.SetProperty(x => x.TextParts, x => x.TextParts.Concat(arr)));

In the Where clause, x.TextParts is properly processed, so we get the IQueryable version of Concat; but inside the ExecuteUpdate, it isn't and we get the IEnumerable version.

One fundamental problem in our design is that nav expansion is in core, and therefore cannot be customized or handle any relational-only things. This means that it's impossible to have a relational- or provider-specific operator that accepts arguments which require nav expansion (e.g. navigations, queryable/enumerable distinction as here).

For ExecuteUpdate specifically, we already have plans to lift ExecuteUpdate/Delete to core in order to allow using it in non-relational providers (#31052); once that's done, we can simply add the proper visitation logic in nav expansion. But the general design situation is problematic.

For this bug specifically, I'm pretty sure the only user-visible regressions are going to affect PG only (because of the array support it already had). So I'll see about hacking around this for now in EFCore.PG, unless we see this raised outside EFCore.PG.

@roji
Copy link
Member Author

roji commented Dec 3, 2023

Note: be careful when doing this, as it would break the PG provider, which currently depends on operators not being queryable, but rather enumerable (see npgsql/efcore.pg#3001). For everything to work correctly, we need to also do #32494, to support full, queryable collection support within ExecuteUpdate.

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

2 participants