search

yogthos / migratus

MIGRATE ALL THE THINGS!
642 stars 93 forks source link

Migratus running migrations already marked as ran #206

Open lucian303 opened 2 years ago

lucian303 commented 2 years ago

I have this row in the schema_migrations table:

20210301103792 2021-09-07 18:00:32.904475 prototype-parirty-changes

and a file called 20210301103792-prototype-parirty-changes.up.sql

yet when I run lein migratus, it still tries to run this migration. How can I make it skip migrations that have already been run (in this case, manually)? What else besides a line in the schema_migrations table does it take and if it looks for some other signal, what is the point of this schema_migrations table?

yogthos commented 2 years ago

It should just be the entry in the migration table that controls whether a particular migration will be run or not.

bjorntorew commented 2 years ago

I have the same problem, using deps.edn. Running against Oracle.

lucian303 commented 2 years ago

After some further investigation, I think I've found the issue. The original schema_migrations table was part of the schema the rest of the database is part of. At some point, migratus created another schema_migrations table that was part of the public schema and decided to use that one. I've removed the one from the original schema and moved the entries to public.schema_migrations and now they are recognized. I'm not sure why, but this seems to be common with migration software when dealing with postgres. A similar thing happened with the completely unrelated doctrine migrations (PHP). Like with that system, this one too may be system dependent, though what decides what schema it ultimately decides to use is a mystery. I'm not sure if the schema needs to be set somewhere in the config or what exactly needs to be done, but for now, I'm just using the table in the public schema and am glad that at the very least it's working.

lucian303 commented 2 years ago

This also seems to be system dependent. Sometimes the schema_migrations table gets put in the correct schema, and sometimes in the public schema. It's just so bizarre that it starts in the right schema and then moves to the wrong (public) one. Then sometimes it just starts in the wrong schema. Anyway, I love the idea of plain SQL migrations, but unfortunately this bug makes the package unusable. Would it be possible to add an explicit configuration option for this? @yogthos

yogthos commented 2 years ago

Yeah, I'm definitely open to adding this as an option. I won't have time to look at it in the near future though, but I'd be glad to help guide a PR if you'd be up for poking around. :)