Add new comment

Thanks for sharing!  Also worth noting that another common error that can occur with this workflow, even if you do drop the database, is refactoring a field to a different type.

For example: You have a textfield "field_summary" which accepts up to 255 characters and the requirement changes and it needs to store more even more text.  So you drop your database, import the remote one, delete that field and re-create it as a Long Text field instead.  Sure, you will lose all your data if you don't manually handle it, but you will be able to get away with this refactor and re-create your feature too.

However, once you try to deploy this, Drupal/Features will choke because it won't know to drop that field before recreating it and will throw an exception when trying to revert that feature.  Now that I think about it, it may be possible to circumvent this by adding an update hook to excplicitly drop that field before reverting the feature.  Either way, it's messy... :)