You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a result, this function in query_table_create.go fails to recognize VARCHAR column in those dialects :
Click for a commented version
func (q*CreateTableQuery) appendSQLType(b []byte, field*schema.Field) []byte {
// Most of the time these two will be identical, but for the cases where DiscoveredSQLType is dialect-specific,// e.g. pgdialect would change sqltype.SmallInt to pgTypeSmallSerial for columns that have `bun:",autoincrement"`iffield.CreateTableSQLType!=field.DiscoveredSQLType {
returnappend(b, field.CreateTableSQLType...)
}
// For all common SQL types except VARCHAR, both UserDefinedSQLType and DiscoveredSQLType specify the correct type,// and we needn't modify it. For VARCHAR columns, we will stop to check if a valid length has been set in .Varchar(int).ifq.varchar>0&&field.CreateTableSQLType==sqltype.VarChar {
b=append(b, "varchar("...)
b=strconv.AppendInt(b, int64(q.varchar), 10)
b=append(b, ")"...)
returnb
}
returnappend(b, field.CreateTableSQLType...)
}
Solution
We could have each dialect provide a method like d.DefaultVarcharLen() and then use that value if no other valid length is specified.
Dialects for which specifying the length is not mandatory (PG, SQLite) could simply return a 0, which would be ignored.
I can do a PR with a fix, if that's indeed a bug and the solution is OK.
The text was updated successfully, but these errors were encountered:
I've encountered this odd behavior with
CreateTableQuery.Varchar(n)
:I've also noticed there is no unit tests that check
.Varchar()
method, so I guess it could be a bug.Problem
Specifying
VARCHAR
length is mandatory in MySQL and MSSQL, so the default 255 is hardcoded in theirDiscoveredSQLType
:bun/dialect/mssqldialect/dialect.go
Line 133 in 733affd
bun/dialect/mysqldialect/dialect.go
Line 178 in 733affd
As a result, this function in
query_table_create.go
fails to recognizeVARCHAR
column in those dialects :Click for a commented version
Solution
We could have each dialect provide a method like
d.DefaultVarcharLen()
and then use that value if no other valid length is specified.Dialects for which specifying the length is not mandatory (PG, SQLite) could simply return a 0, which would be ignored.
I can do a PR with a fix, if that's indeed a bug and the solution is OK.
The text was updated successfully, but these errors were encountered: