search

rubenv / sql-migrate

SQL schema migration tool for Go.
MIT License
3.19k stars 273 forks source link

Support custom MigrationRecord types/tables #72

Closed fgrosse closed 7 years ago

fgrosse commented 7 years ago

If the migration table already exists with more columns than the internal MigrationRecord knows then PlanMigration would fail.

With this commit these non fatal errors are silently ignored.

rubenv commented 7 years ago

@fgrosse What's the use case for this?

fgrosse commented 7 years ago

It allows us to have more columns in the migrations table than rubenv/sql-migrate is aware of. This is useful when using sql-migrate with a migration table that is also used by other tooling.

As an example I added a test where the migrations table has an author column. I don't want sql-migrate to crash if this extra column exists.

rubenv commented 7 years ago

@fgrosse I'm not sure if that's a wise thing to do. What happens if at some point a column is added inside sql-migrate that conflicts?

Wouldn't it be better to have a second table with your additional columns, that you can join?

I'd rather have the sql-migrate table be considered as "private namespace": don't touch it.

Could you give an example of the other tooling?

fgrosse commented 7 years ago

I see your point but it seems wrong to add another table for migration data if I already have such a table. I am currently just playing with using the library and implemented a couple of ideas when I stumbled upon this issue. To me it was suprising that migrations would fail if I add a column to the migrations table so I created a PR to fix it :)

I can't give you an example of that tooling since thats what I am working on at the moment and I am not sure yet how it will look at the end (or if I actually end up needing extra columns at all). At the moment I am trying to implement some kind of table locking to avoid race conditions when two migrations are triggered simultaneously. I could imagine adding information like who ran the migration, how long did it take, etc...

rubenv commented 7 years ago

I could imagine adding information like who ran the migration, how long did it take, etc...

But all of that would be added by a tool outside of sql-migrate, right? Then why should it alter the migrations table?

I'm sorry, but experience tells me that these things usually lead to trouble.

Use a JOIN table: it'll cause less trouble if and when sql-migrate alters its schema and it's just good common sense to keep things separate.

fgrosse commented 7 years ago

OK no problem.