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
Before goctl/v1.6.6, whether signed or unsigned in database tables, they were all converted to signed types in the end.
bigint case
`xx`bigint unsigned NOT NULL,
Regardless of whether there was unsigned before, they all ended up generating go int64.
But starting from goctl/v1.6.6 upgrade, the above fields will default to go -> uint64, even if you haven't configured strict = true. According to the documentation, when strict = false and no custom type is specified, it should still maintain bigint -> int64.
The current behavior is not compatible with previously generated versions, which is breaking.
Describe the bug
this pr:#4062 add a strict mod.
Before goctl/v1.6.6, whether signed or unsigned in database tables, they were all converted to signed types in the end.
bigint
caseRegardless of whether there was unsigned before, they all ended up generating go int64.
But starting from goctl/v1.6.6 upgrade, the above fields will default to
go -> uint64
, even if you haven't configuredstrict = true
. According to the documentation, whenstrict = false
and no custom type is specified, it should still maintain bigint -> int64.The current behavior is not compatible with previously generated versions, which is breaking.
The reason seems to be that the following two places did not check strict.
https://github.com/zeromicro/go-zero/blob/master/tools/goctl/model/sql/converter/types.go#L308
https://github.com/zeromicro/go-zero/blob/master/tools/goctl/model/sql/converter/types.go#L275
But in DefaultNull condiction, use strict
And in some DefaultNulll, the strict checking is included.
https://github.com/zeromicro/go-zero/blob/master/tools/goctl/model/sql/converter/types.go#L285
Expected behavior
Compatible with previous versions
Screenshots
Environments (please complete the following information):
The text was updated successfully, but these errors were encountered: