The fix is easy; catch the exception and ignore it. All unit tests still pass with this modification, and this also allows sql-sync to work when the target database exists and is empty.

If no one has any issues with this, I will commit it.

Comments

moshe weitzman’s picture

I'm hesitant to add this so late in the cycle. If it were local to a command, I might go for it. maybe we do this right after 7.x opens?

greg.1.anderson’s picture

StatusFileSize
new1.53 KB

Here is a fix for sql-conf only. This will still allow sql-sync to work after an sql-drop. Unit tests are running right now; I expect they will all pass.

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

This looks fine, pending green tests

greg.1.anderson’s picture

Status: Reviewed & tested by the community » Postponed

All green; committed.

Setting to 'postponed' to reconsider #0 in Drush-8.x-7.x.

greg.1.anderson’s picture

Version: 8.x-6.x-dev » 7.x-5.x-dev
Status: Postponed » Patch (to be ported)

What do you think about putting this into 7.x-5.x-dev? The situation is quite annoying to get out of, as you can't use Drush on the target, and you can't sql-sync over the target. The workaround is to delete the db completely and then use --create-db, or copy your database configuration into your alias record. :(

moshe weitzman’s picture

seems ok to backport

greg.1.anderson’s picture

Version: 7.x-5.x-dev » 8.x-6.x-dev
Status: Patch (to be ported) » Postponed

All tests passed, so committed to 7.x-5.x. Back to 'postponed' until 8.x-7.x.

greg.1.anderson’s picture

Status: Postponed » Closed (won't fix)
Issue tags: +Needs migration

This issue was marked closed (won't fix) because Drush has moved to Github.

If desired, you may copy this bug to our Github project and then post a link here to the new issue. Please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.