Optimistic concurrency check should be configurable

[MarcoLoetscher]

How concurrency tokens work in EF. UPDATE and DELETE commands are treated equally in EF Core. I think the DELETE command should only have the primary key in the WHERE clause. If an entity has already been deleted by another user, DbUpdateConcurrencyException should't be thrown because it is not relevant. If I want to delete an entity, it is also not relevat whether it has been changed in the meantime by another user.

In an UPDATE command the WHERE clause should be configurable, like the DataSet. It should be possible to include all the modified properties in the WHERE clause (ConflictOption.CompareAllSearchableValues).
DbCommandBuilder.ConflictOption Property, ConflictOption Enumeration
I am aware that the concurrency check in EF core is the same as in EF 6.x, but I think that things can be improved in EF Core.
Thanks a lot.

[roji]

The question of disabling concurrency checking for delete is covered by #10443, see specifically #10443 (comment); this is part of a larger question of allowing more configurability around optimistic concurrency. For example, doing optimistic concurrency checking on updates usually makes no sense if no concurrency token isn't defined.

The other thing requested by the OP is the ability to define all properties as concurrency tokens. I think that's an anti-pattern in most (possibly all) cases, for performance reasons. However, we already allow defining multiple concurrency tokens, so the user is free to do that if they wish; a user convention could allow automating this as well.

So proposing to close this as a dup of #10443.

[roji]

Duplicate of #10443