Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate migration-free SQL scripts for test cases #34603

Closed
ewlloyd opened this issue Sep 3, 2024 · 2 comments
Closed

Generate migration-free SQL scripts for test cases #34603

ewlloyd opened this issue Sep 3, 2024 · 2 comments

Comments

@ewlloyd
Copy link

ewlloyd commented Sep 3, 2024

The Problem

Our integration test suite creates and tears down the test database many times during each test run. Given the 170 migrations we've accumulated so far (and counting), this leads to some pretty inefficient DDL.

The Solution

What I propose is a command-line flag (say, --squash or --direct) that instructs EF to generate a DDL script that lays out the final schema directly, with no intermediate migration states.

This script, while it would be much more efficient for building transient test databases, would be dangerous to run against an existing database. To that end, some guard logic could be tacked on at the top of the script to defend against this: See the __EFMigrationsHistory table? Abort the run before you destroy something.

@roji
Copy link
Member

roji commented Sep 3, 2024

That sounds like #2174 (squashing migrations). Or if you're looking for a feature which wouldn't actually get rid of the migrations on disk, but only generate a squashed SQL script, it would most probably depend on it (i.e. we could implement this by temporarily squashing everything in memory etc.).

But if you get to the point where it's too slow to run all the migrations in the tests, wouldn't you also just want to squash the migrations on disk as well?

@ewlloyd
Copy link
Author

ewlloyd commented Sep 3, 2024

We have our specific reasons for maintaining the chain of migrations in our solution that I won't go into here (mainly because I'm not the one driving that policy), but indeed, as you said yourself, we just want to have a squashed script for maximum efficiency during testing.

Looking at some of the comments on #2174, I see I'm not the first to see the benefits of this.

@cincuranet cincuranet closed this as not planned Won't fix, can't repro, duplicate, stale Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants