✅ What's the point of ModelSnapshot in ef core migrations
I'm trying to move my migrations to a separate projects in case I want to change a db provider. I've moved my existing migrations to the separate project and that's what I've got now:
In my
Application.Core
project I've added the following config for DI:
I didn't add x => x.MigrationsAssembly("WebApplication1.Migrations")
call as it shown in the docs (https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/projects)
My questions is: how come EF still works even though it doesn't reference Migrations project where AppContextModelSnapshot
is stored? And what are potential issues with my approach?22 Replies
i use a different assembly/project for migrations
what do you mean by "ef core still works"
I mean that I still can query database altough project where dbcontext is doesn't reference project with migrations, which contains
AppContextModelSnapshot
which has modelbuilder setupmigrations and snapshot aren't needed for dbcontext
so the modebuilder configuration is not actually used during runtime? Because this kinda confused me, because I can write the same configuration (for example for replationships) if I override it
are you migrating your database at runtime?
migrations are not your model, they describe how to modify your database when you change your model
The ModelSnapshot is not used at runtime. It's used by the designer tool to generate migrations, and possibly some of its other functions
the ModelBuilder configuration is very much used at runtime, and is also used to generate ModelSnapshots
No, migrations are being run in that separate project with migrations in CI
Got it, thanks. Got confused because both
BuildModel
and OnModelCreating
are accepting ModelBuilder
where's
BuildModel
?hmm
oh
so, that method's not empty, right?
yeah, I've omitted it
yeah, the snapshot is just another method of building a model
so, like
I was confused because actually
BuidModel
can contain the same configurations as OnModelCreating
canyeah, that's by design
But now I understand that it's purely for migrations
so, when you run the designer tool to generate a migration
and those are actually generated from models +
OnModelCreating
it calls that
BuildModel()
method to generate a model, in memory, which represents (in thoery) the current state of the physical database
and it does the same thing for DbContext.OnModelCreating()
to generate a model, in memory, of whta you WANT the database to be
then it can effectively diff those two object structures
that's where the migration code comes fromUnderstood
that file also gives you, as the developer, the chance to modify it, if you have anything to model that EF doesn't properly support
same for the migration code itself
Guess my question is answered
Thanks again for the explanation
Remind me, how to properly resolve the question here
There was a command or something
uhhhhhhhhhhhhhhhh