Skip to content
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

Added support for migrations with comments (mysql only) #25

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

bwjohnson-ss
Copy link

I wanted a way for gomigrate to print out comments/status inside a migration. This only applies for mysql, since it's the only supported db type with multi-command migrations.

Copy link
Owner

@DavidHuie DavidHuie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments.

@@ -238,6 +239,18 @@ func (m *Migrator) ApplyMigration(migration *Migration, mType migrationType) err

// Perform the migration.
for _, cmd := range commands {
cmd = strings.ReplaceAll(cmd, "\n", "") // strip off leading whitespace
if strings.HasPrefix(cmd, "SELECT") && strings.HasSuffix(cmd, "AS comment") {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to normalize the query here with strings.ToLower?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say yes for any SQL keywords, but that would mess up the capitalization of other strings that we may not want to mess with.

@@ -3,11 +3,15 @@ CREATE TABLE test (
PRIMARY KEY (id)
);

SELECT 'my comment' AS comment;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps any select should be printed out? I see no other reason to include selects in migrations.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see that being helpful, but in the migrate func I specifically chose to use the transaction.QueryRow interface func since it would always return only one row. I guess you could allow someone to run a query that returned multiple rows, but then you'd open up more possibilities and you could inadvertently spam your gomigrate output with tons of rows.

m.logger.Printf("Error executing query comment: %v", err)
return err
}
m.logger.Printf("Comment: %v", comment)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if I like the term "comment" to refer to this. Maybe "debug output" works best?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see merit in that too, but would you prefer adding a new opt-in flag on the migrator to enable SELECT comments/debug statements? I could also be fine with no prefix label and just print out the raw comment/debug statement too. Thoughts?

@bwjohnson-ss
Copy link
Author

@DavidHuie Any thoughts to my above comments?

@bwjohnson-ss
Copy link
Author

Ping? @DavidHuie ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants