Schema versioning pattern with Cosmos DB

[alexeymarkov]

Hello,

I would like to implement the schema versioning pattern with for EF Core Cosmos DB.
I do not care about missing properties in queries and indexes and just want to have a full backward compatibility with old versions and avoid service downtime.
So the idea was to add a shadow property "schema_version" to each entity and and to migrate the data if necessary during reading.

Questions:

1. How to intercept data reading (I need to read and modify a pure JObject before EF builds a real entity from it)
2. How to intercept data writing to add the shadow property

Thank you.

[alexeymarkov]

I found a solution myself.

For intercept reading I replace CosmosClientWrapper in DbContext and override ExecuteSqlQueryAsync method.
The class is for internal purposes so I would like to have an official way to implement lazy migrations.

For intercept writing I override SaveChangesAsync in DbContext. Due to the bug that HasValueGenerator does not affect Update despite of configuring together with ValueGeneratedOnAddOrUpdate I have to set values for modified entities in SaveChangesAsync.
It would be good to see ValueGeneratedOnAddOrUpdate behaves as expected (not as ValueGeneratedOnAdd).

[Dazfl]

I'm faced with the same problem at the moment ... schema versioning. I would love to see this feature added to EF Core for Cosmos DB.

[roji]

Please upvote issues in this repo (thumbs up on top-most message) to indicate that you want it implemented.

[jhulbertpmn]

I’d love to see built-in support for this as well

[davidfowl]

I tried to add a property and it works fine locally, but failed when I deployed to azure...

[roji]

See #21006 for having a default value when reading missing properties, specifically for the (very common) scenario of adding a new property with existing documents.