Panic when using dialect: mysql

[lluchs]

With dialect: mysql I get the following when running sql-migrate up:

panic: gorp - undefined MySQLDialect.Engine, MySQLDialect.Encoding. Check that your MySQLDialect was correctly initialized when declared.

Looking at the source, the engine and encoding need to be set somehow. Am I missing some option?

[rubenv]

Oh damn, I hadn't tested with MySQL. Looks like we'll need to figure out a way to pass dialect options.

The good news is that we can fix this internally. Only time the gorp dialect is used is when the migrations table is updated.

I'll push a fix.

[rubenv]

I've pushed a possible fix.

Try updating sql-migrate (the -u option triggers an update):

go get -u github.com/rubenv/sql-migrate/...

I've reopened the issue to make sure we don't lose track of it. Let me know if it works.

[lluchs]

Awesome, thanks. sql-migrate up works fine now, but sql-migrate status prints the following error:

sql: Scan error on column index 1: unsupported driver -> Scan pair: []uint8 -> *time.Time

The gorp_migrations table looks fine:

mysql> select * from gorp_migrations;
+--------------------+---------------------+
| id                 | applied_at          |
+--------------------+---------------------+
| 1.entity_state.sql | 2014-09-24 10:38:39 |
+--------------------+---------------------+
1 row in set (0.00 sec)

Edit: In fact, sql-migrate up works just once and prints the same error now.

Edit 2: Looking at the MySQL driver documentation, this can be fixed by adding ?parseTime=true to the datasource string. This should probably be noted in the README or, if possible, automatically added.

[rubenv]

if possible, automatically added.

I'm not sure that we can, since the sql.DB is supplied externally (we can off-course do it in the command-line tool).

Seems like this is only needed when you use Go-MySQL-Driver, the other one (mymysql) does parse dates correctly.

Is there a way to detect that a) it's a Go-MySQL-Driver connection and b) it doesn't have the required setting?

[lluchs]

I don't think it's possible to add the parameter to existing connections anyways, so it's probably best to just document this somewhere.

The command-line tool would have to parse the connection string and append either ?parseTime=true or &parseTime=true. I'm afraid that just looking for an existing ? wouldn't work as the password can contain question marks.

[rubenv]

We can probably add a check for this: if the dialect is mysql, do a simple SELECT NOW() and try to scan it into a time.Time. If that fails: fail and show instructions on how to correct it.

[rubenv]

I'll have a look at adding scripted tests for the tool as well, these can do full integration tests with the database, that should prevent future failures.

[rubenv]

There's a warning now, which will inform you to add the parseTime flag.

Also check the test-integration folder, which contains end-to-end tests that hit the database (the Travis environment is configured to run these).