Description
I use gin + gorm + postgresql
I defined consts:
const (
cpnTypeCheckbox uint8 = 20
CpnTypeCascader uint8 = 50
)
In postgrelsql, column cpn_type type is int4, length is 32
my model definition:
type BizGenerateTableFieldConfig struct {
Id uint `json:"id,omitempty"`
GenerateTableId uint `json:"generateTableId,omitempty"`
FieldNameEn string `json:"fieldNameEn,omitempty"`
CpnType uint8 `json:"cpnType,omitempty"`
CpnMaxLen uint `json:"cpnMaxLen,omitempty"`
FieldRelationType uint8 `json:"fieldRelationType,omitempty"`
RelationTarget string `json:"relationTarget,omitempty"`
RelationTargetDesc string `json:"relationTargetDesc,omitempty"`
RelationTargetFieldNameForLabel string `json:"relationTargetFieldNameForLabel,omitempty"`
RelationTargetFieldNameForValue string `json:"relationTargetFieldNameForValue,omitempty"`
RequiredFields []string `json:"requiredFields,omitempty" gorm:"serializer:json"`
ApiSelectOptionConfigId string `json:"apiSelectOptionConfigId,omitempty"`
CreateTime *time.Time `json:"createTime,omitempty"`
UpdateTime *time.Time `json:"updateTime,omitempty"`
}
func (t *BizGenerateTableFieldConfig) TableName() string {
return "biz_generate_table_field_config"
}
golang business code:
var configs []model.BizGenerateTableFieldConfig
db.Where("generate_table_id = ?", param.BizGenerateTableId).Where("cpn_type IN ?", []uint8{global.CpnTypeCheckbox, global.CpnTypeCascader}).Find(&configs)
then, it's report error, sql log:
2022/06/14 09:37:40 E:/code/GoglandProjects/ybt_dynamic_pro/controller/generate.go:308 ERROR: syntax error at or near "$2" (SQLSTATE 42601)
[3.544ms] [rows:0] SELECT * FROM "biz_generate_table_field_config" WHERE generate_table_id = 79 AND cpn_type IN '<binary>'
when I write code like this:
var configs []model.BizGenerateTableFieldConfig
db.Where("generate_table_id = ?", param.BizGenerateTableId).Where("cpn_type IN ?", []string{fmt.Sprintf("%v", global.CpnTypeCheckbox), fmt.Sprintf("%v", global.CpnTypeCascader)}).Find(&configs)
it's successful.
so, I hope the gorm can support int array for where in condition, not only string array for where in condition.
Comment From: ccpwcn
I used gorm v1.23.6
Comment From: github-actions[bot]
The issue has been automatically marked as stale as it missing playground pull request link, which is important to help others understand your issue effectively and make sure the issue hasn't been fixed on latest master, checkout https://github.com/go-gorm/playground for details. it will be closed in 30 days if no further activity occurs. if you are asking question, please use the Question template, most likely your question already answered https://github.com/go-gorm/gorm/issues or described in the document https://gorm.io ✨ Search Before Asking ✨
Comment From: a631807682
Cause by https://github.com/go-gorm/gorm/commit/07960fe
Based on what considerations do we need to support byte? It will lead to inconsistent behavior below.
us := []uint8("byte")
// SELECT * FROM `users` WHERE id IN 'byte' AND `users`.`deleted_at` IS NULL
DB.Where("id IN ?", us).Find(&user)
// SELECT * FROM `users` WHERE id IN (98,121,116,101) AND `users`.`deleted_at` IS NULL
DB.Raw("SELECT * FROM `users` WHERE id IN (?) AND `users`.`deleted_at` IS NULL", us).Find(&user)
@jinzhu
Comment From: github-actions[bot]
The issue has been automatically marked as stale as it missing playground pull request link, which is important to help others understand your issue effectively and make sure the issue hasn't been fixed on latest master, checkout https://github.com/go-gorm/playground for details. it will be closed in 30 days if no further activity occurs. if you are asking question, please use the Question template, most likely your question already answered https://github.com/go-gorm/gorm/issues or described in the document https://gorm.io ✨ Search Before Asking ✨
Comment From: jinzhu
inconsistent
the commit is submitted even before the public release of v2, so it should be fine.
for the question, maybe you can change to use []int8, in golang, byte is a alias of uint8, we can't know if you are passing a []byte or not.