> 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 j

> 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` in each one (my tool also supports `pre` and `post` SQLs at either the migration level, or the 'global' level, but that's a pretty niche option I'd suggest. For reference my tool is called `mallard`: https://bitbucket.org/koalephant/mallard https://bitbucket.org/koalephant/mallard and the Python tool that inspired it is called `dbschema`: https://github.com/gabfl/dbschema https://github.com/gabfl/dbschema