-
-
Notifications
You must be signed in to change notification settings - Fork 580
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
Consider supporting *.mysql file type for import-db #516
Milestone
Comments
We can re-open if anyone else trips up on this. |
rfay
added a commit
to rfay/ddev
that referenced
this issue
May 4, 2018
rfay
added a commit
to rfay/ddev
that referenced
this issue
May 10, 2018
rfay
added a commit
to rfay/ddev
that referenced
this issue
May 14, 2018
rfay
added a commit
to rfay/ddev
that referenced
this issue
May 14, 2018
As a frequent user of backup_migrate for its one-click downloads of remote databases (and I can't be the only one) this would be a big help. |
Please open a new issue with your request, thanks! |
Done #1483 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened (or feature request):
Rick noted with a ddev demo that an import of a backup-migrate module backup failed. For example,
ddev import-db --src=APLVDatabaseBackup-2017-10-23T06-30-32.mysql.gz
:The issue here is that backup-migrate uses the very nonstandard ".mysql" file type inside the gzip file, and ddev recognizes only the more-likely ".sql" filetype.
backup-migrate has gzip files like
APLVDatabaseBackup-2017-10-23T06-30-32.mysql.gz
containing a file likeAPLVDatabaseBackup-2017-10-23T06-30-32.mysql
. If you gunzip and give the .mysql file to ddev import-db, it imports just fine.It shouldn't be hard to expand our vision to looking for *.mysql as equivalent to *.sql
The text was updated successfully, but these errors were encountered: