You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the case of migratus, it identifies that table names should be keywords, and throws a spec validation error. This first occurs when marking the table as reserved prior to running migrations, and exceptions thrown at this point are swallowed; migratus is unable to mark the migrations table as reserved, and assumes this is because somebody else has already reserved the table, so it skips running the migrations, and marks the table as unreserved again (which also fails spec validation).
The expected behaviour is:
Migratus marks table as reserved
Migratus attempts to run migrations
Migratus marks table as unreserved
The observed behaviour is:
Migratus fails to mark table as reserved
Migratus doesn't attempt migrations
Migratus fails to mark table as unreserved
Migratus logs an INFO message (not an ERROR) which says Migration reserved by another instance. Ignoring.
To reproduce:
Run (next.jdbc.specs/instrument) prior to running migrations with Migratus.
A workaround is not to instrument next.jdbc functions for spec, but that's functionality that I'd like to have elsewhere in my codebase, so it's a shame to lose it. An error in the logs when Migratus fails to mark a table as reserved for a non-sql reason would help with debugging this issue.
The text was updated successfully, but these errors were encountered:
This was a fun one!
The friendly functions in next.jdbc expect table names as keywords, but Migratus passes them as strings.
Normally this is fine, because the friendly functions delegate to next.jdbc.sql.builder/for-insert which calls the next.jdbc.sql.builder/safe-name function that turns the table name into a string anyway. So usually there isn't a problem. Usually!
I use clojure.spec and had enabled next.jdbc's spec instrumentation, which checks arguments passed to next.jdbc functions.
In the case of migratus, it identifies that table names should be keywords, and throws a spec validation error. This first occurs when marking the table as reserved prior to running migrations, and exceptions thrown at this point are swallowed; migratus is unable to mark the migrations table as reserved, and assumes this is because somebody else has already reserved the table, so it skips running the migrations, and marks the table as unreserved again (which also fails spec validation).
The expected behaviour is:
The observed behaviour is:
INFO
message (not an ERROR) which saysMigration reserved by another instance. Ignoring.
To reproduce:
Run
(next.jdbc.specs/instrument)
prior to running migrations with Migratus.A workaround is not to instrument next.jdbc functions for spec, but that's functionality that I'd like to have elsewhere in my codebase, so it's a shame to lose it. An error in the logs when Migratus fails to mark a table as reserved for a non-sql reason would help with debugging this issue.
The text was updated successfully, but these errors were encountered: