Cosmos: Add support for executing pre- and post-triggers #36505

AndriySvyryd · 2025-08-05T18:29:25Z

Fixes #19944

Copilot

Pull Request Overview

This PR adds support for executing pre- and post-triggers in Cosmos DB by implementing trigger configuration and execution in Entity Framework Core. The changes enable developers to define database triggers on entity types and have them automatically executed during SaveChanges operations.

Key changes:

Added trigger type configuration through fluent API with IsPreTrigger() and IsPostTrigger() methods
Implemented trigger execution in the Cosmos client wrapper during create and replace operations
Added comprehensive validation to ensure triggers are only defined on root entity types and have proper type configuration

Reviewed Changes

Copilot reviewed 15 out of 16 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
`CosmosTriggersTest.cs`	New functional test that verifies trigger execution during SaveChanges operations
`CosmosModelValidatorTest.cs`	Unit tests for trigger validation including derived type and missing type detection
`CosmosBuilderExtensionsTest.cs`	Tests for trigger builder extensions and configuration source handling
`CosmosTriggerType.cs`	New enum defining Pre and Post trigger types
`CosmosTriggerExtensions.cs`	Extension methods for getting/setting trigger types on trigger metadata
`CosmosTriggerBuilderExtensions.cs`	Fluent API extensions for configuring trigger types
`CosmosEntityTypeBuilderExtensions.cs`	Entity type builder extensions for defining triggers
`CosmosClientWrapper.cs`	Core implementation that attaches triggers to Cosmos DB operations
`CosmosModelValidator.cs`	Validation logic for trigger configuration rules
`CosmosStrings.resx`	Error message resources for trigger validation
`CosmosAnnotationNames.cs`	New annotation name constant for trigger type metadata
Entity type interfaces	Added `GetTriggers()` method across all entity type interfaces

Files not reviewed (1)

src/EFCore.Cosmos/Properties/CosmosStrings.Designer.cs: Language not supported

test/EFCore.Cosmos.FunctionalTests/CosmosTriggersTest.cs

AndriySvyryd · 2025-08-06T00:07:22Z

src/EFCore.Cosmos/Extensions/CosmosTriggerBuilderExtensions.cs

+    /// <param name="triggerBuilder">The builder for the trigger being configured.</param>
+    /// <param name="triggerType">The trigger type to configure.</param>
+    /// <returns>The same builder instance so that multiple configuration calls can be chained.</returns>
+    public static TriggerBuilder HasTriggerType(this TriggerBuilder triggerBuilder, TriggerType triggerType)


This introduces public methods, so API review needs to be done as part of the PR review.
Note that TriggerType and TriggerOperation are from Cosmos SDK

SamMonoRT · 2025-08-06T12:04:12Z

cc fyi @Pilchie

Pilchie · 2025-08-06T17:52:09Z

Also tagging @kirankumarkolli .

AndriySvyryd · 2025-08-06T20:55:41Z

test/EFCore.Cosmos.FunctionalTests/CosmosTriggersTest.cs

+                entity.HasTrigger("PreInsertTrigger")
+                    .HasTriggerType(TriggerType.Pre).HasTriggerOperation(TriggerOperation.Create);
+                entity.HasTrigger("PostDeleteTrigger")
+                    .HasTriggerType(TriggerType.Post).HasTriggerOperation(TriggerOperation.Delete);
+                entity.HasTrigger("UpdateTrigger")
+                    .HasTriggerType(TriggerType.Pre).HasTriggerOperation(TriggerOperation.Replace);


Here's an example of the new API usage

Aren't the trigger type and operation mandatory? If so, I'd expect HasTrigger to have them as required parameters, no?

I get that there will be edge cases where someone wants to change the type/operation for a trigger that has already been defined, but in the 99% case users just want to define a new trigger (it might be acceptable for the edge case to just use the metadata APIs directly).

Makes sense. I'll combine them into one method here, but leave separate on the Metadata API

roji · 2025-08-07T08:01:39Z

test/EFCore.Cosmos.FunctionalTests/CosmosTriggersTest.cs

+                entity.HasTrigger("PreInsertTrigger")
+                    .HasTriggerType(TriggerType.Pre).HasTriggerOperation(TriggerOperation.Create);
+                entity.HasTrigger("PostDeleteTrigger")
+                    .HasTriggerType(TriggerType.Post).HasTriggerOperation(TriggerOperation.Delete);
+                entity.HasTrigger("UpdateTrigger")
+                    .HasTriggerType(TriggerType.Pre).HasTriggerOperation(TriggerOperation.Replace);


Aren't the trigger type and operation mandatory? If so, I'd expect HasTrigger to have them as required parameters, no?

I get that there will be edge cases where someone wants to change the type/operation for a trigger that has already been defined, but in the 99% case users just want to define a new trigger (it might be acceptable for the edge case to just use the metadata APIs directly).

roji · 2025-08-07T08:12:25Z

src/EFCore.Cosmos/Storage/Internal/CosmosClientWrapper.cs

        var container = wrapper.Client.GetDatabase(wrapper._databaseId).GetContainer(parameters.ContainerId);
        var itemRequestOptions = CreateItemRequestOptions(entry, wrapper._enableContentResponseOnWrite);
        var partitionKeyValue = ExtractPartitionKeyValue(entry);
+        var preTriggers = GetTriggers(entry, TriggerType.Pre, TriggerOperation.Create);


Am noting that when performing an update using the Cosmos SDK, users need to manually specify which triggers they want executed; this is very different from relational database triggers, where the trigger is defined on the table and then automatically (and always) runs when the table is updated, without any client request.

This EF implementation seems to provide relational-like behavior, i.e. the user defines the trigger on the model and then the trigger gets implicitly used in SaveChanges (a more Cosmos-faithful implementation would allow the user to specify triggers to be executed on each SaveChanges). FWIW the relational behavior generally makes more sense to me as a developer experience, but maybe we should confirm this proposed behavior with the Cosmos people? i.e. maybe there's some reason we're missing for wanting users to manually specify triggers?

I'd be interested to hear thoughts on this from the Cosmos team. But from what I've seen online this is the behavior that most users are looking for.
Also, from a technical perspective, we don't have a way of flowing provider-specific parameters through SaveChanges. If we did, we could add a way of opting out for specific triggers.

Filed #36525

roji · 2025-08-07T08:14:38Z

test/EFCore.Cosmos.FunctionalTests/CosmosTriggersTest.cs

+        }
+    }
+
+    private async Task CreateTriggersInCosmosAsync(TriggersContext context)


Don't we want EF to create the triggers with the Cosmos SDK? i.e. allow the user to configure the Javascript in the model and then do the CreateTriggerAsync call?

That's out of scope for this PR. Also, without schema versioning, this would not be useful/recommended in production

Filed #36524

Pilchie · 2025-08-07T15:16:43Z

And tagging @TheovanKraay too.

Fixes #19944

roji · 2025-08-11T18:50:05Z

Oops this had auto-merge :(

AndriySvyryd requested a review from Copilot August 5, 2025 18:29

AndriySvyryd requested a review from a team as a code owner August 5, 2025 18:29

Copilot AI reviewed Aug 5, 2025

View reviewed changes

AndriySvyryd force-pushed the Issue19944 branch from c5b9812 to 3382dfc Compare August 6, 2025 00:06

AndriySvyryd commented Aug 6, 2025

View reviewed changes

AndriySvyryd force-pushed the Issue19944 branch from 3382dfc to 32e7845 Compare August 6, 2025 01:40

AndriySvyryd commented Aug 6, 2025

View reviewed changes

roji reviewed Aug 7, 2025

View reviewed changes

Cosmos: Add support for executing pre- and post-triggers

fff0a1a

Fixes #19944

AndriySvyryd force-pushed the Issue19944 branch from 32e7845 to fff0a1a Compare August 7, 2025 19:07

AndriySvyryd enabled auto-merge (squash) August 7, 2025 19:08

roji approved these changes Aug 11, 2025

View reviewed changes

AndriySvyryd merged commit 54033a4 into main Aug 11, 2025
7 checks passed

AndriySvyryd deleted the Issue19944 branch August 11, 2025 18:46

AndriySvyryd mentioned this pull request Aug 11, 2025

Document Cosmos trigger execution dotnet/EntityFramework.Docs#5080

Closed

roji added rc-1 and removed rc-1 labels Sep 8, 2025

Copilot AI mentioned this pull request Sep 26, 2025

Document Cosmos trigger execution support dotnet/EntityFramework.Docs#5114

Merged

Cosmos: Add support for executing pre- and post-triggers #36505

Cosmos: Add support for executing pre- and post-triggers #36505

Uh oh!

Conversation

AndriySvyryd commented Aug 5, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SamMonoRT commented Aug 6, 2025

Uh oh!

Pilchie commented Aug 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pilchie commented Aug 7, 2025

Uh oh!

Uh oh!

roji commented Aug 11, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants