✅ doubts about migrations
what's bothering me: every time we do a migration on our main service we have 8K+ lines more to commit in the project
(which btw means that for example in the vs search i have to exclude migrations path - thing that took ages because it didn't work - or it's useless)
it's not a big deal di per se, but i find it kinda silly that project is what, ~150K loc, and we have 1+ M loc of migrations (around 100 tables (i'm working on isolating some parts, but i don't know if/when that'll happen) and almost 400 migrations) because every migration (ef core) does a new snapshot
so is this how it's supposed to be? is it not? would i be better off moving migrations to another solution? is there a way to save some code?
i've seen somewhere that maybe you can squash some migrations together, but a) atm i don't know how to do that b) im not sure i want, maybe some i could but with the first ones i don't think i would save that much
6 Replies
What problem would you solve by moving them into another problem or squashing them?
@Omnissiah do you really need to store all 400 migrations. You can probably keep the latest 100 migrations and ignore the rest.
You can also perhaps try to zip the directory.
so i have not really any technical hard problem, or at least not one i was not able to solve (like the search thing)
for example even compilation speed is not that much of an issue (still)
so apart that i find it in some way absurd that 90% of the project is migration code, it would please me to have a more reasonable sized repo
people also says to delete the "guilty" designer.cs files
i don't know at this point i would just try move it to another project rather
i would have to search if there are still old services around that don't need really migrations anymore
Are the designer and migration files even icluded in the compilation?
yes, compiled dll is 15 MB so...
Yeah right thinking about it, they have to be or EFCore could not migrate the DB at runtime.