Skip to content

Conversation

@globalchubby
Copy link

@globalchubby globalchubby commented Dec 28, 2025

I think #917 highlights the issue that both Dialect and string can represent a dialect, and both are accepted in public APIs. For example, compare the signatures of goose.SetDialect and goose.NewProvider. This is a problem because Dialect looks like a valid enum, but it can actually be any string.

Long-term, it might be better to only accept strings in the public API, but that's a breaking change.

This PR adds a helper function database.ParseDialect that given a string returns the corresponding Dialect value, if any. It's used to fix #917, but by shifting the responsibility to Goose users: users using any public API that accepts a Dialect can obtain a valid Dialect value by calling ParseDialect.

I'm also wondering what you think these changes imply for OpenDBDriver? I'm also curious about some of the driver rewrites there which conflict with the logic in ParseDialect, e.g.

	switch driver {
	case "mssql":
		driver = "sqlserver"
	case "tidb":
		driver = "mysql"         // why? this maps to "tidb" in ParseDialect
	case "spanner":
		driver = "spanner"       // this is unnecessary?
	case "turso":
		driver = "libsql"        // this conflicts w/ ParseDialect logic
	case "sqlite3":
		driver = "sqlite"
	case "postgres", "redshift": // this conflicts w/ ParseDialect logic
		driver = "pgx"
	case "starrocks":            // this conflicts w/ ParseDialect logic
		driver = "mysql"
	}

@globalchubby globalchubby changed the title database: Use ParseDialect to accept aliases and return canonical dialect (closes #917) database: Use ParseDialect to accept dialect aliases and return canonical dialect (closes #917) Dec 28, 2025
d = DialectTurso
case "starrocks":
d = DialectStarrocks
case "dsql":
Copy link
Author

Choose a reason for hiding this comment

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

This case is new. The lookup map in NewStore has an entry for it, so we should support it here as well.

// Dialect is the type of database dialect.
type Dialect string

var ErrUnknownDialect = errors.New("unknown dialect")
Copy link
Author

Choose a reason for hiding this comment

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

Since we're returning the same error in two places, I thought it better to have a sentinel error. I debated having an error type instead, but the only data I could think of it holding is the unknown dialect, but the caller already has this.

// aliases, e.g. "postgres" or "pgx". Use this function to ensure that a [Dialect] instance
// passed to any function that accepts a [Dialect] is a valid [Dialect].
func ParseDialect(s string) (d Dialect, err error) {
// Every non-error return value from this function must have an entry in the [NewStore] lookup map.
Copy link
Author

@globalchubby globalchubby Dec 28, 2025

Choose a reason for hiding this comment

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

To really prevent drift, instead of having a comment here, what do you think of having a registry? I drafted up a PR in globalchubby#1.

@globalchubby globalchubby changed the title database: Use ParseDialect to accept dialect aliases and return canonical dialect (closes #917) database: Use database.ParseDialect to accept dialect aliases and return canonical dialect (closes #917) Dec 28, 2025
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.

Inconsistent dialect check (sqlserver)

1 participant