Allow passing complex type instances to `ExecuteUpdate`

[xamir82]

Imagine this model:

public class User
{
    public int Id { get; set; }
    public required FullName FullName { get; set; }
}

[Owned]
public class FullName
{
    public required FirstName { get; set; }
    public required LastName { get; set; }
}

Inserting a User with by assigning a FullName object to the FullName property works:

db.Add(new User
{
    FullName = someFullNameObj,
});
db.SaveChanges();

But doing the same with ExecuteUpdate doesn't work:

db.Users.Where(u => u.Id == userId)
    .ExecuteUpdate(b => b
        .SetProperty(u => u.FullName, someFullNameObj)
    );

It throws an exception along these lines:

The LINQ expression ... could not be translated. The following lambda argument to 'SetProperty' does not represent a valid property to be set: 'u => u.FullName'.

This is an unexpected asymmetry between how insert and update work, I think most people would intuitively expect the ExecuteUpdate example to work just fine, it's a bit surprising, a weird limitation.

Let me know if there's an existing issue for this.

[roji]

ExecuteUpdate doesn't (currently) support passing an entire owned object; it requires you reference properties that map to columns in the database. Simply decompose the owned instance as follows:

db.Users
    .Where(u => u.Id == userId)
    .ExecuteUpdate(b => b
        .SetProperty(u => u.FullName.FirstName, someFullNameObj.FirstName)
        .SetProperty(u => u.FullName.LastName, someFullNameObj.LastName)
    );

[xamir82]

@roji Thanks for the quick response!
You're right, and that's the workaround I'm currently using. But don't you plan to support passing an entire owned object? Is there an issue tracking that? It'd be much more convenient when your method is actually receiving an owned type instance to simply pass it directly, as opposed to tediously call SetProperty on all its individual properties.

And also: Would EF8's complex types support this? Or do they have the same problem?

[roji]

@xamir82 I do think we should support this, but given that you can decompose to individual property setters this would simply be a bit of sugar, nothing more. So I'd say this is quite low-priority compared to our other issues.

Complex types will have the same limitation, yes.

[aradalvand]

Turns out this is not merely a nice-to-have as has been implied here, there would actually be no way to use ExecuteUpdate to update a collection backed by a JSON column without this very feature.

@roji Don't you think it would make sense to add the consider-for-current-release tag to this issue, given that?

[roji]

I don't think there's anything special regarding collections here: just like you can't replace a standalone object within JSON (that's not in a collection), you can't replace an object that's within a collection. And once #28766 is implemented, you could modify all the properties within an object in a collection, in the same way you would for an object not within a collection.

So unless I'm mistaken, passing in an entire entity instance still effectively be a nicer alternative to listing out the properties one-by-one - or am I missing something?

[aradalvand]

So unless I'm mistaken, passing in an entire entity instance still effectively be a nicer alternative to listing out the properties one-by-one - or am I missing something?

@roji Well, how would you do the equivalent of the following, even if #28766 was implemented?

db.Products.ExecuteUpdate(b => b.SetProperty(p => p.Traits, newTraits));

(where newTraits is e.g. a List<Trait> that is coming from somewhere else (an API client, for example), and should simply replace the current traits.)

[roji]

That's not an entity instance - it's a list of instances. We can indeed track that here as part of this issue, though it would likely require it's own specific work... In any case, I've put the consider-for-current-release label on this.

[aradalvand]

That's not an entity instance - it's a list of instances. We can indeed track that here as part of this issue

I guess I assumed that this represents basically the same underlying problem (or at least that they're related). So yes, I think it does make sense to track it here. @xamir82 perhaps you could adjust the title of the issue a little bit to reflect this more clearly? Thanks.

In any case, I've put the consider-for-current-release label on this.

Thank you very much!