-
-
Notifications
You must be signed in to change notification settings - Fork 95
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
Migratus running migrations already marked as ran #206
Comments
It should just be the entry in the migration table that controls whether a particular migration will be run or not. |
I have the same problem, using deps.edn. Running against Oracle. |
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. |
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 |
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. :) |
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?
The text was updated successfully, but these errors were encountered: