Changing TRUNCATE for a DELETE in the SetVersion Method #585
Conversation
Pull Request Test Coverage Report for Build 463
💛 - Coveralls |
|
|
||
| import ( | ||
| "github.com/golang-migrate/migrate/v4/database" | ||
| "github.com/hashicorp/go-multierror" |
There was a problem hiding this comment.
Move this line back up so imports are grouped. e.g. built-in modules -> 3rd party modules -> intra-package imports
| } | ||
|
|
||
| query := "TRUNCATE `" + m.config.MigrationsTable + "`" | ||
| query := "DELETE FROM `" + m.config.MigrationsTable + "`" |
There was a problem hiding this comment.
Did you also try a DROP + CREATE?
It seems like that was the approach MySQL took in v8.
What are the differences in behavior and performance between TRUNCATE and DELETE?
Since this table should be small, I don't expect a significant performance difference.
I don't think DELETE will create a table lock where as DROP will. Also, it looks like neither DROP or TRUNCATE can be rolledback.
There was a problem hiding this comment.
We should centralize the discussion :) . So yes, DELETE can be rolled back, and neither DROP nor TRUNCATE can as you mentioned. That's the main issue. The other issue is the performance of TRUNCATE in servers with a large buffer pool that affects 5.7 and below.
Also, delete will create a lock over all the rows in the table, but not a TABLE LOCK, if that is what you need (lock the table), you could use LOCK TABLES instead but I don't think that it is really needed because all other transactions will be waiting for the rowlock anyway.
Regards,
Martin.
|
Closed in favor of #656 |
3 participants
Since MySQL does not support transactions for DDLs, I have changed the TRUNCATE statement for a DELETE FROM, which is transactional.
The details are explained in issue #584