Closed b-ryan closed 8 months ago
From the stack trace, it looks like do-commands is expecting an unwrapped connection object, but it ends up being passed a map of {:connection conn}
instead.
could you try the following locally to see if it would address the issue
(cond
(instance? Connection connectable)
(with-open [stmt (prepare/statement connectable)]
;; We test for (string? commands) because migratus.test.migrations.sql tests fails otherwise.
;; Perhaps it is a bug in migratus.test.mock implementation ?!
(if (string? commands)
(run! #(.addBatch stmt %) [commands])
(run! #(.addBatch stmt %) commands))
(into [] (.executeBatch stmt)))
(map? connectable)
(do-commands (:connection connectable) commands)
:else
(with-open [conn (jdbc/get-connection connectable)]
(do-commands conn commands)))
That change does appear to fix the issue. I had to modify the test a bit; perhaps there's a better way to test this, but since migrate/down close the connection, I did it likeso:
(deftest test-no-tx-migration-pass-conn
(with-open [assertions-conn (jdbc/get-connection (:db config))]
(let [assertions-config (assoc config
:migration-dir "migrations-no-tx"
:db {:connection assertions-conn})
test-config #(assoc assertions-config :db {:connection (jdbc/get-connection (:db config))})]
(is (not (test-sql/verify-table-exists? assertions-config "foo")))
(core/migrate (test-config))
(is (test-sql/verify-table-exists? assertions-config "foo"))
(core/down (test-config) 20111202110600)
(is (not (test-sql/verify-table-exists? assertions-config "foo"))))))
Related to that, but perhaps this warrants a separate issue, it would be nice to have an option to leave connections open and let the calling code manage the connection. Being that the caller is the one opening the connection, it makes some sense to me that they should manage closing it too.
Agreed, I think it would make sense to allow connection to be managed externally. I guess one option might be to add a new config flag such as :managed-connection
that would hint Migratus to avoid trying to close it so that the new behavior will be backwards compatible.
Any chance you'd be up to do a PR for the changes? :)
Yeah I can do that
I will make a separate issue for the managed connection stuff to keep the PR for this issue smaller.
Sounds like a plan, and I can do a release once both PRs are in.
It seems like the simple combination of using
:disable-transaction
in a SQL migration along with passing in a rawConnection
object is enough to throw an exception. This test code demonstrates:Error:
I tried digging in to fix it, but I'm not really sure where things are going wrong.