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
I was working on some SQL migrations and had a syntax error in my SQL script. I had an up and down migration that were both run as part of my tests. The exception that I got was:
#error{:cause "ERROR: syntax error at or near \"ALTER\"\nPosition: 43",
:via [{:type org.postgresql.util.PSQLException,
:message "ERROR: syntax error at or near \"ALTER\"\nPosition: 43",
:at [org.postgresql.core.v3.QueryExecutorImpl receiveErrorResponse "QueryExecutorImpl.java" 2477]}],
:trace [[org.postgresql.core.v3.QueryExecutorImpl receiveErrorResponse "QueryExecutorImpl.java" 2477]
[org.postgresql.core.v3.QueryExecutorImpl processResults "QueryExecutorImpl.java" 2190]
[org.postgresql.core.v3.QueryExecutorImpl execute "QueryExecutorImpl.java" 300]
If you look deep in the stack frames you can see that they were part of the rollback, not the migration, but as I was debugging I didn't think to look there (because of the voluminous stack frames).
I wonder if it would be useful to catch exceptions thrown during running a migration and rethrowing them? You could add an intermediate ex-info which contains information about the migration ID and direction that was being run.
This seems like it would be especially useful if you needed to write multiple migrations in one go, as it could be hard to determine which of the migrations threw the exception.
One problem with this idea is that it might break any code that was trying to catch specific exceptions when running a migration.
The text was updated successfully, but these errors were encountered:
I was working on some SQL migrations and had a syntax error in my SQL script. I had an up and down migration that were both run as part of my tests. The exception that I got was:
If you look deep in the stack frames you can see that they were part of the rollback, not the migration, but as I was debugging I didn't think to look there (because of the voluminous stack frames).
I wonder if it would be useful to catch exceptions thrown during running a migration and rethrowing them? You could add an intermediate
ex-info
which contains information about the migration ID and direction that was being run.This seems like it would be especially useful if you needed to write multiple migrations in one go, as it could be hard to determine which of the migrations threw the exception.
One problem with this idea is that it might break any code that was trying to catch specific exceptions when running a migration.
The text was updated successfully, but these errors were encountered: