Skip to content

Commit

Permalink
Document 7.0 SaveChanges incompatibility with some computed columns
Browse files Browse the repository at this point in the history 
Closes #4130
  • Loading branch information
@roji
roji committed Nov 14, 2022
1 parent cb6f750 commit 56ffaaf
Show file tree
Hide file tree
Showing 2 changed files with 18 additions and 18 deletions.
6 changes: 3 additions & 3 deletions entity-framework/core/providers/sql-server/misc.md
View file
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
View file
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

0 comments on commit 56ffaaf

Please sign in to comment.