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

Document 7.0 SaveChanges incompatibility with some computed columns #4131

Merged
merged 1 commit into from
Nov 15, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions entity-framework/core/providers/sql-server/misc.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,15 +7,15 @@ uid: core/providers/sql-server/misc
---
# Miscellaneous notes for SQL Server

## SaveChanges and database triggers
## SaveChanges, database triggers and unsupported computed columns

Starting with EF Core 7.0, EF Core saves changes to the database with significantly optimized SQL; unfortunately, this technique is not supported on SQL Server if the target table has database triggers. For more information on this SQL Server limitation, see the documentation on the [OUTPUT clause](/sql/t-sql/queries/output-clause-transact-sql).
Starting with EF Core 7.0, EF Core saves changes to the database with significantly optimized SQL; unfortunately, this technique is not supported on SQL Server if the target table has database triggers, or certain kinds of computed columns. For more information on this SQL Server limitation, see the documentation on the [OUTPUT clause](/sql/t-sql/queries/output-clause-transact-sql#remarks).

You can let EF Core know that the target table has a trigger; doing so will revert to the previous, less efficient technique. This can be done by configuring the corresponding entity type as follows:

[!code-csharp[Main](../../../../samples/core/SqlServer/Misc/TriggersContext.cs?name=TriggerConfiguration&highlight=4)]

Note that doing this doesn't actually make EF Core create or manage the trigger in any way - it currently only informs EF Core that triggers are present on the table. As a result, any trigger name can be used.
Note that doing this doesn't actually make EF Core create or manage the trigger in any way - it currently only informs EF Core that triggers are present on the table. As a result, any trigger name can be used, and this can also be used if an unsupported computed column is in use (regardless of triggers).

A model building convention can be used to configure all tables with triggers:

Expand Down
30 changes: 15 additions & 15 deletions entity-framework/core/what-is-new/ef-core-7.0/breaking-changes.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,17 +16,17 @@ EF Core 7.0 targets .NET 6. This means that existing applications that target .N

## Summary

| **Breaking change** | **Impact** |
|:-------------------------------------------------------------------------------------------------------------|------------|
| [`Encrypt` defaults to `true` for SQL Server connections](#encrypt-true) | High |
| [Some warnings will again throw exceptions by default](#warnings-as-errors) | High |
| [SQL Server tables with triggers now require special EF Core configuration](#sqlserver-tables-with-triggers) | High |
| [Orphaned dependents of optional relationships are not automatically deleted](#optional-deletes) | Medium |
| [Cascade delete is configured between tables when using TPT mapping with SQL Server](#tpt-cascade-delete) | Medium |
| [Key properties may need to be configured with a provider value comparer](#provider-value-comparer) | Low |
| [Check constraints and other table facets are now configured on the table](#table-configuration) | Low |
| [Navigations from new entities to deleted entities are not fixed up](#deleted-fixup) | Low |
| [Using `FromSqlRaw` and related methods from the wrong provider throws](#use-the-correct-method) | Low |
| **Breaking change** | **Impact** |
|:---------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| [`Encrypt` defaults to `true` for SQL Server connections](#encrypt-true) | High |
| [Some warnings will again throw exceptions by default](#warnings-as-errors) | High |
| [SQL Server tables with triggers or certain computed columns now require special EF Core configuration](#sqlserver-tables-with-triggers) | High |
| [Orphaned dependents of optional relationships are not automatically deleted](#optional-deletes) | Medium |
| [Cascade delete is configured between tables when using TPT mapping with SQL Server](#tpt-cascade-delete) | Medium |
| [Key properties may need to be configured with a provider value comparer](#provider-value-comparer) | Low |
| [Check constraints and other table facets are now configured on the table](#table-configuration) | Low |
| [Navigations from new entities to deleted entities are not fixed up](#deleted-fixup) | Low |
| [Using `FromSqlRaw` and related methods from the wrong provider throws](#use-the-correct-method) | Low |

## High-impact changes

Expand Down Expand Up @@ -108,7 +108,7 @@ protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)

<a name="sqlserver-tables-with-triggers"></a>

### SQL Server tables with triggers now require special EF Core configuration
### SQL Server tables with triggers or certain computed columns now require special EF Core configuration

[Tracking Issue #27372](https://github.com/dotnet/efcore/issues/27372)

Expand All @@ -118,19 +118,19 @@ Previous versions of the SQL Server saved changes via a less efficient technique

#### New behavior

By default, EF Core now saves changes via a significantly more efficient technique; unfortunately, this technique is not supported on SQL Server if the target table has database triggers.
By default, EF Core now saves changes via a significantly more efficient technique; unfortunately, this technique is not supported on SQL Server if the target table has database triggers, or certain types of computed columns. See the [SQL Server documentation](/sql/t-sql/queries/output-clause-transact-sql#remarks) for more details.

#### Why

The performance improvements linked to the new method are significant enough that it's important to bring them to users by default. At the same time, we estimate usage of database triggers in EF Core applications to be low enough that the negative breaking change consequences are outweighed by the performance gain.
The performance improvements linked to the new method are significant enough that it's important to bring them to users by default. At the same time, we estimate usage of database triggers or the affected computed columns in EF Core applications to be low enough that the negative breaking change consequences are outweighed by the performance gain.

#### Mitigations

You can let EF Core know that the target table has a trigger; doing so will revert to the previous, less efficient technique. This can be done by configuring the corresponding entity type as follows:

[!code-csharp[Main](../../../../samples/core/SqlServer/Misc/TriggersContext.cs?name=TriggerConfiguration&highlight=4)]

Note that doing this doesn't actually make EF Core create or manage the trigger in any way - it currently only informs EF Core that triggers are present on the table. As a result, any trigger name can be used.
Note that doing this doesn't actually make EF Core create or manage the trigger in any way - it currently only informs EF Core that triggers are present on the table. As a result, any trigger name can be used, and this can also be used if an unsupported computed column is in use (regardless of triggers).

A model building convention can be used to configure all tables with triggers:

Expand Down