Skip to content

Conversation

maumar
Copy link
Contributor

@maumar maumar commented Apr 2, 2025

No description provided.

AndriySvyryd and others added 4 commits March 8, 2025 00:28
…Table Causes Issues with Subsequent Table Recreation (#35776)

Port of #35764

Fixes #35162

Description
Problem was that in 9.0 we changed how we process temporal tables, tracking the temporal table information as we process migrations. However, we didn't take into account the cases where users would manually modify their migrations, or squash multiple migrations together, resulting in corrupted dictionary access for cases where a table was deleted and created in the same migration. This fix just makes the temporal information map handling more robust, so those errors don't happen anymore. There is a broader issue with temporal tables but those will be addressed in a different PR.

Customer impact
Some manually modified/squashed migrations no longer work when they are being applied, throwing an unhelpful exception (The given key '...' was not present in the dictionary.'). No good workaround apart from breaking the migrations apart.

How found
Reported by multiple customers on 9.

Regression
Yes.

Testing
Added infra to test these types of scenarios (containing intermediate migration state), added multiple tests both for regular and temporal tables.

Risk
Low - Very targeted fix, accessing the temporal information dictionary in a more robust way. No quirk, since migrations are design time, so hard to set switches for them.
…35782)

Description
Problem was that we don't have a good story for schema evolution in Cosmos (e.g. adding a new non-nullable property). We start generating shaper code expecting the new schema, but the old documents are not being updated. Effectively, querying for those modified entities stops working because the document no longer matches the expected shape. This is a major pain point and adoption blocker for EF Core Cosmos users. While designing a compelling schema evolution story is a large task and out of scope for now, we believe we can solve majority of the problems with a targeted change - when generating shaper for Cosmos entities, if required value is not present, we generate the CLR default rather than throw.

Customer impact
EF Core customers using Cosmos experience exceptions when querying for an entity which had it's schema modified, e.g. by adding a non-nullable property. There is no good workaround, apart from manually adding missing data to the document or using nullable properties instead.

How found
Reported by multiple customers on 9.

Regression
No.

Testing
Added multiple tests for scalar and reference scenarios, all supported types, converters vs no. missing value vs explicit nulls.

Risk
Low - Targeted fix, when constructing non-nullable property of an entity type we produce default of that type, rather than null. This does not affect keys, just regular scalar properties.
Potential negative side-effect is that we lose the validation for scenarios where legitimate required property is introduced, but the value hasn't been provided for it in the document by accident.
Added a quirk as an escape hatch to revert to previous behavior.

Fixes #21006
@maumar maumar changed the title Merge branch 'release/9.0' => 'release/9.0-staging' Merge branch 'release/9.0-staging' => 'release/9.0' Apr 2, 2025
@maumar maumar requested a review from AndriySvyryd April 2, 2025 21:36
@maumar maumar enabled auto-merge (squash) April 3, 2025 01:44
@maumar maumar disabled auto-merge April 3, 2025 01:44
@maumar maumar enabled auto-merge April 3, 2025 01:45
@maumar maumar merged commit 894a90b into release/9.0 Apr 3, 2025
7 checks passed
@maumar maumar deleted the merge_staging_905 branch April 3, 2025 16:04
This was referenced Jul 21, 2025
This was referenced Sep 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants