Add new comment

Oh, yes, I'd forgotten about sql-create: in itself it's definitely neater than the DROP/CREATE statements. But (for reasons of defense in depth) Drupal's MySQL user shouldn't have permission to create databases, so I'm assuming you'd need extra command-line options to specify a more privileged MySQL user. At that point, it starts to approach the verbosity of DROP/CREATE.

More broadly, I think people just aren't used to cruft tables suddenly being orphaned in the database, when they're in the thick of iterating on what feels like their code, that should be predictable by them. I've spoken to a couple of devs now who treat these PDO exceptions as arcane and not entirely predictable, so I think it's instructive to have a forensic breakdown of where they've come from, how to get rid of them and what it means when you get to the production environment, where you don't have the privilege of running sql-create.

You're right, though, that it's best practice to always drop the entire database before importing a database dump. Mind you, if everyone always followed best practice, we'd probably have much less use for diagnostic modules like schema...!