Maintain consistency in transactional DBs

[chrismwendt]

This PR aims to solve DB inconsistency mentioned in #325 by letting transactional DB drivers handle setting the version and dirty flag when running a migration.

• Adds a method Transactional() bool to the Driver interface
• Skips calling SetVersion in migrate.go for transactional drivers
• Adds a version argument to Run so that transactional drivers know which version to set upon success
• Updates the Postgres driver to make use of a transaction

Try it out by following the "alternative" instructions in https://github.com/chrismwendt/golang-migrate-consistency

TODO

• Implement transactional migrations for transactional drivers
  • SQLite
  • MySQL
  • ...others
• Clean up the string munging in postgres.go

[dhui]

This change is backwards incompatible.
See: #14 (idea 4) and #196

We should discuss the new driver interface in #14 before continuing work on this

[chrismwendt]

In what way(s) is this change backwards incompatible? It's not immediately obvious to me how "existing migrations using with BEGIN/COMMIT will break" #196 (comment). Is it because not all DBs support nested transactions?

Is it possible to make this backwards compatible?

@dhui Are you actively working on a new driver implementation? Would you prefer to include this change into a new driver implementation #14 or merge this sooner when it's in a satisfactory state?

[dhui]

In what way(s) is this change backwards incompatible? It's not immediately obvious to me how "existing migrations using with BEGIN/COMMIT will break" #196 (comment). Is it because not all DBs support nested transactions?

The existing recommendation is to wrap migrations in a transaction if the DB allows for it. Migrations are also treated as opaque blobs. So any change to manage transactions at the driver level will break old/existing migrations that use transactions.

Is it possible to make this backwards compatible?

Maybe? But I can't think of a way w/o inspecting migrations.

@dhui Are you actively working on a new driver implementation? Would you prefer to include this change into a new driver implementation #14 or merge this sooner when it's in a satisfactory state?

I am not actively working on a new implementation. It's still unclear what the ideal new driver interface would look like. I'd like avoid making too many backwards incompatible changes so will be batching all known backwards incompatible changes into one major release.