mg reset fails due to constraints
Opened this issue · 4 comments
I have a number of tables with foreign key constraints. When I try to run mg reset it fails because the drop needs to either happen in reverse order of create or specify CASCADE. I'd say the former is better, since CASCADE would mean later drops might encounter missing tables that were already removed.
Of course, right now there is no tracking of creation order, unless each table was created as a separate migration, so not sure how this should be handled
Sorry for the late response!
Yes. That is a known issue of mg reset. It was not directly supported by Slick at that time and I don't know if anything changed since then.
If the database you use happen to have some easy ways to reset your database, you can implement that in the migration_manager sub-project under your project. Otherwise, some ways to handle foreign key constraints is indeed needed.
Dropping tables in reverse order sounds an interesting idea! But I'm not sure how does this work with migrations that alter tables and adds foreign keys to later created tables? Tracking table update time will not work, because I don't know any easy ways to check whether altering table changes the foreign key constraints...
Been thinking more about the reset issue. I wonder if the solution might be to add the concepts of reverse migrations. This is a common mechanism in rails, django, where it's called up/down or undomigrations in flywheel. I see that the Migration trait already has def up, so adding def down might already be a consideration.
I don't know of any elegant general solution, but for Postgres I tend to drop "public" and then recreate it, that way you don't have to think about the relations
UP / DOWN would be the "right" way to do it, for simple cases DOWN could be inferable (maybe a feature for slick-migration-api?)
From working with rails, I'm a little sceptical of the operational value of 'down' migrations - as soon as you've got a database of any size, even hypothetically reversible ones can take a lot of care to apply correctly, so it's best to stick to going forward. A 'clean' down has some value at development time, however, when you're iterating on the migration itself.
Since the only conceivable use of mg reset is to wipe everything out completely, it seems to me that CASCADE is the better option for that specific scenario...