Revisit model-snapshot for perf

[ajcvickers]

At the beginning of EF Core we decided that we would use the fluent API in model snapshots rather than designing a new serialization format. (In other words, the fluent API is the way to serialize the model.) However, this can lead to a lot of code compiled for big models and when the number of migrations build up. See, for example, #18618.

We should consider:

• A different snapshot serialization, potentially based on the compiled model (when it exists, see Reduce EF Core application startup time via compiled models #1906)
• Mitigate by supporting squash for migrations: Squash migrations #2174
• Some more extensive overhaul of the migrations experience

[AndriySvyryd]

Note that this will likely mean that snapshots will need to be updated for major version upgrades and possibly minor ones. So we should consider #18557 at the same time

[bricelam]

Another idea I has was to only put the store model in the *.Designer.cs files, but this doesn't work since we need the full model when removing a migration.

[ajcvickers]

We believe this is best handled by squashing migrations: #2174

[ajcvickers]

Re-open to consider using the relational model.

[Tasteful]

I was trying to work around this in our product that have ~440 migrations and we can't squash them into a single to get a fresh start because the product is installed on-premises at customer and different customer is in different stage of upgrades in versioning.

I come up to the solution where I created a MSBuild task that extracting the attributes from the *.Designer.cs files and generated a new file. Then I adding a targets file that excluding all the *.Designer.cs files and including the generated file. This somehow is working in many cases but some CreateIndexOperations will add an filter [Id] IS NOT NULL even on non-nullable properties and this does not happen when running the original code.

The generated file does not contain the BuildTargetModel file where all the metadata about the model at that time the model was created is ignored, this reduced the size for the built assembly from 32 MB to 2 MB and build time from 2 minutes and 30 seconds to 8 seconds so that is a good improvements in speed.

Does it exists any information about how the model in BuildTargetModel is used during migration up command?

Should it work to run the migrations up command without the model in BuildTargetModel ?

[bricelam]

Does it exists any information about how the model in BuildTargetModel is used during migration up command?

This answer is old and there are probably more cases now, but it should give you an idea of how the model is used..