dbschema

> I was simply using it against local databases, and yes that does make for a weak excuse as to why SSL is not supported. It's one of the reasons I chose to just write my tool in shell and call `mysql` directly, (ab)using the 'sectioned' nature of mysql .cnf files for config, so that any possible mysql option can be set for the connection, without needing to handle it in-app. > For this to work the revisions would need to be changed from standalone SQL files, to actual directories themselves. Not that big of an issue, but perhaps something I will look into. Ideally I want this tool to play nice with other tools in regards to the data it produces. That's essentially how mine, and the python one before it worked: a root 'migrations' directory somewhere, with named subdirectories representing each migration, and then `up.sql` and `down.sql`

I’ve been using a couple of python tools wrapped in two shell scripts to achieve what I think works well: migration-capture.sh (using https://github.com/mmatuson/SchemaSync) creates a temporary db using a base schema SQL file, applies previously created migrations, and then creates up/down migration scripts by comparing that to a db that’s been modified manually or by an mvc model tool, etc. migration-apply.sh (using https://github.com/gabfl/dbschema) applies the “up” scripts that haven’t been applied previously OR runs the “down” scripts corresponding to “up” scripts that have been run previously but are not found in the deployed scripts (ie rolling back a deployment automatically runs the down script for migrations that were in the rolled back versions) Right now my only concern/goal for improvement with the setup is to replace the pyth