New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing TRUNCATE for a DELETE in the SetVersion Method #585
Conversation
Pull Request Test Coverage Report for Build 463
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR!
"github.com/golang-migrate/migrate/v4/database" | ||
"github.com/hashicorp/go-multierror" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move this line back up so imports are grouped. e.g. built-in modules -> 3rd party modules -> intra-package imports
@@ -329,7 +324,7 @@ func (m *Mysql) SetVersion(version int, dirty bool) error { | |||
return &database.Error{OrigErr: err, Err: "transaction start failed"} | |||
} | |||
|
|||
query := "TRUNCATE `" + m.config.MigrationsTable + "`" | |||
query := "DELETE FROM `" + m.config.MigrationsTable + "`" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, let's keep the discussion in the issue.
Closed in favor of #656 |
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