Skip to content

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.

// 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.

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?

Copy link

@matt-subsplash matt-subsplash Aug 27, 2025

Choose a reason for hiding this comment

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

Since the term comment is used in the ANSI/ISO SQL lexicon, I think calling it a comment is perfectly valid. Perhaps SQL Comment: is more descriptive?

@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.

3 participants