-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Allow users to fail when there are bad migration paths in their source #1048
Comments
OMG this is such an annoying thing. I just lost 2-3 hours to something that should be basic. Thank you for reporting. |
If one can make migrations invisible by incorrect filename, then that should be advertised more prevalently in the docs. There should also be more flexibility in the naming structure of migrations. Why so strict without declaring what the parameters of strictness are more loudly? Seems like this issue makes it kindof difficult to test that your migrations are being "seen" by the library, too. |
0001_test.up.sql - Works 0001-test.up.sql - Doesn't work
0001-test-up.sql - Doesn't work
0001-up-test.sql - Doesn't work
0001_up_add-test-table.sql - Doesn't work
Not everyone uses the same regex when they think up file names that apply to their product. Please fail migrations when there are files that don't conform to the regex, or be more flexible. |
Is your feature request related to a problem? Please describe.
When initializing migrate with a
file
source, we noticed that migrate silently ignores bad file paths (i.e.003_some_migration.up copy.json
). We don't expect migrate to allow these bad filenames to run, but we were stumped for some time on why a particular migration didn't run (we hadn't noticed the bad filename).Describe the solution you'd like
We would like to initialize migrate in a more "strict" way, i.e. fail when there are bad filepaths in the source location, or provide us with a function to validate our source location before initializing migrate.
Describe alternatives you've considered
What we currently do is use the regex from
source/parse.go
in a validate function and run it against our migration directory.Additional context
Happy to elaborate more if needed.
The text was updated successfully, but these errors were encountered: