Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when using SQL mode and a migration contains a syntax error,
db-migrate
will only print the error message and call stack:Even for a medium sized migration SQL file,
syntax error at or near ")"
can be like finding a needle in a haystack.When using
pg
, the Error actually contains additional information with the exact position of the syntax error. But currently, that information is not logged, as explicitly only thestack
of the error is logged.This PR changes it so that the entire error object is logged. Node's behavior when an
Error
is passed toconsole.error()
(which is used under the hood bylog.js
) is to log only thestack
property if there are no additional properties, meaning there would be no difference in those cases.But if there are additional properties, Node will log both the
stack
with message, and any properties after it:In particular, the
position
here can be copy-pasted into an editor's "go to position" command to jump exactly to the syntax error in the SQL file.Other properties can be helpful in case e.g. a DB constraints gets violated by the migration, as it can contain the constraint name, offending column values, etc.
One small change is also necessary to make sure the error gets properly logged: Throw the actual error if it's an
Error
instance instead of wrapping it in anAssertionError
, as the AssertionError just adds additional noise to the log and since the Error gets nested under theactual
property, it doesn't get expanded in the log but reduced to only[DatabaseError]
.There may be a small benefit in wrapping in an error given the error may not be an
Error
instance, but if it is, it makes more sense to throw the error directly.