golang 个人使用GORM的一点教训

发表于： 2018年12月20日 2018年12月20日
分类：未分类

GORM血泪史。

GORM是个很好用的工具，就是有时候脑抽，容易写出非常隐蔽的错误。

本文总结了个人使用GORM的教训，纯属个人观点。如有错误，请多多指正，谢谢。

一、批量新增

（1）错误示范

表结构：

// User represents table `user`.

type User struct {

ID string `gorm:"type:varchar(32)"`

.....

}

如果要批量新增几个用户，可能会一时脑抽，写成这样：

user.go

func TestInsert(userList []table.User , tx *gorm.DB) error {

for _, u := range userList {

err := tx.Create(table.User{

ID:u.ID,

.....

}).Error

if err != nil {

return err

}

return nil

}

首先这样写是没问题的，能达到批量新增用户的目的。但是这不是最优雅的实现方式，这里应该使用批量新增。

（2）正确实践

那么问题来了，GORM根本没有批量新增的支持，我们只能自己实现一个。

下面是CJK大佬写的批量新增方法：

batch.go

// Row ...

type Row []interface{}

// BatchInsert constructs and executes batch insert SQL.

func BatchInsert(db *gorm.DB, table string, columns []string, rows []Row) error {

if len(rows) == 0 {

return nil

}

sql := fmt.Sprintf("INSERT INTO %s(%s) VALUES ", table, strings.Join(columns, ","))

length := len(columns)

var valueHolders []string

for i := 0; i < length; i++ {

valueHolders = append(valueHolders, "?")

}

placeHolder := fmt.Sprintf("(%s)", strings.Join(valueHolders, ","))

var values []string

var args []interface{}

for _, row := range rows {

if len(row) != length {

return fmt.Errorf("Row (%v) does not match columns (%v)", row, columns)

}

values = append(values, placeHolder)

args = append(args, row...)

}

sql += strings.Join(values, ",")

return db.Exec(sql, args...).Error

}

实际上是自己封装了要插入的SQL，然后使用执行原生SQL的方式进行插入操作。

使用时，需要指定批量插入的字段，并且封装要插入的数据：

user.go

func TestInsert(userList []table.User, tx *gorm.DB) error {

rows := make([]model.Row, 0)

for _, u := range userList {

row := model.Row{u.ID}

rows = append(rows, row)

}

err := model.BatchInsert(tx, "user", []string{"id"}, rows)

if err != nil {

return err

}

return nil

}

能一条SQL搞定的批量插入，就不要分多条SQL插入。

二、删除

（1）错误示范

表结构：

// Probation represents table `probation`.

type Probation struct {

ID uint

UserID string `gorm:"type:varchar(32);NOT NULL;index:idx_user_id"`

.....

}

写一个删除方法：

func TestDelete(userID string, tx *gorm.DB) error {

err := tx.Delete(table.Probation{UserID:userID}).Error

if err != nil {

return err

}

return nil

}

假设userID = “xie4ever”。现在尝试执行TestDelete方法，请问真的能删除 user_id = “xie4ever” 的数据吗？

实际执行的语句为：

1	DELETE * FROM probation;

userID条件没有起任何作用，整张表都被清空了…这个案例破坏力巨大，请不要轻易尝试。

个人认为这是GORM里的一个大坑，如果你这样写：

1	tx.Delete(table.Probation{UserID:userID})

在delete时，只会以主键（即ID）作为删除条件，因为UserID不是主键，所以delete时没有附带任何where条件。

换句话说，如果你想删除 ID = “xie4ever” 的数据，使用：

1	tx.Delete(table.Probation{ID:id})

的写法是可行的。

（2）正确实践

正确的删除方式：

func TestDelete(userID string, tx *gorm.DB) error {

err := tx.Delete(table.Probation{}, "user_id = ?", userID).Error

if err != nil {

return err

}

return nil

}

这样也可以：

func TestDelete(userID string, tx *gorm.DB) error {

err := tx.Where("user_id = ?", userID).Delete(table.Probation{}).Error

if err != nil {

return err

}

return nil

}

但是要注意第二种删除方式，不能把where条件写在delete操作后面：

1	tx.Delete(table.Probation{}).Where("user_id = ?", userID)

这样的删除语句相当于没有带where条件。

三、修改

（1）错误示范

表结构：

// Report represents table `report`.

type Report struct {

UserID string `gorm:"type:varchar(32);PRIMARY_KEY"`

SickLeave float64 `gorm:"type:decimal(3,1);NOT NULL"`

.....

}

写一个修改方法：

func TestUpdate(userID string ,sickLeave float64, tx *gorm.DB) error {

err := tx.Model(table.Report{}).

Where("user_id = ?",userID).Update(

table.Report{

SickLeave:sickLeave,

}).Error

if err != nil {

return err

}

return nil

}

假设userID = “xie4ever”，sickLeave = 0。现在尝试执行TestUpdate方法，请问真的能更新sick_leave字段的值为0吗？

结果是不行的，我们查看一下官方文档：

http://gorm.io/zh_CN/docs/update.html

提到了：

// WARNING when update with struct, GORM will only update those fields that with non blank value

// For below Update, nothing will be updated as "", 0, false are blank values of their types

db.Model(&user).Updates(User{Name: "", Age: 0, Actived: false})

如果你用struct为载体进行更新，所有字段都不能被更新为0值（或Null值），而且这次操作是不会报错的，非常隐蔽。

（2）正确实践

正确的更新方式：

func TestUpdate(userID string ,sickLeave float64, tx *gorm.DB) error {

err := tx.Model(table.Report{}).

Where("user_id = ?",userID).Update(

map[string] interface{} {

"sick_leave":sickLeave,

}).Error

if err != nil {

return err

}

return nil

}

可以使用map作为载体进行更新。

func TestUpdate(userID string ,sickLeave float64, tx *gorm.DB) error {

err := tx.Raw("UPDATE report SET sick_leave = ? WHERE user_id = ?",sickLeave,userID).Error

if err != nil {

return err

}

return nil

}

使用原生SQL也可以。考虑到可能更新很多字段，还是使用map的方式比较靠谱。

四、查询

（1）错误示范

表结构：

// User represents table `user`.

type User struct {

ID string `gorm:"type:varchar(32)"`

.....

}

如果要查看一个用户是否存在，可能会手抖写成这样：

func IsUserExist(id string, tx *gorm.DB) bool {

return !tx.Model(table.User{}).Where("id = ?",id).RecordNotFound()

}

假设id = “xie4ever”。现在尝试执行IsUserExist方法，请问真的能判断 id = “xie4ever” 的数据是否存在吗？

真的不能，因为这里漏写了一个Scan()方法，没有执行任何查询操作，RecordNotFound()的结果永远为true，导致IsUserExist()方法的结果永远为false。

这个错误也是非常隐蔽的，测试正常数据时不容易发现问题（比如我要插入一个User，需要事先校验ID是否会冲突，结果永远为false，顺利通过校验后容易造成主键冲突，事后比较难发现是校验步骤出了问题）。

（2）正确实践

正确的查询方法：

func IsUserExist(userID string, tx *gorm.DB) bool {

var user table.User

return !tx.Model(table.User{}).Where("user_id = ?",userID).Scan(&user).RecordNotFound()

}

这样写才会正常执行SQL。

五、执行原生查询SQL

（1）错误示范

之前有个同事尝试使用Exec()方法执行查询SQL，结果没有正常执行。我建议他换用Raw()方法，查询就正常了。结果他非要和我说：“我之前是可以的，Exec()是可以执行查询语句的…”，没办法，我只好亲自试一试了…

表结构：

// User represents table `user`.

type User struct {

ID string `gorm:"type:varchar(32)"`

.....

}

手写原生SQL，查询指定id的user：

func TestSelectUser(userID string, tx *gorm.DB) *table.User {

var user table.User

tx.Exec("SELECT * FROM user WHERE id = ?" , userID).Scan(&user)

return &user;

}

注意这里使用了Exec()方法，不是通常使用的Raw()方法。

假设id = “xie4ever”。现在尝试执行TestSelectUser方法，请问真的能查询到 id = “xie4ever” 的数据吗？

日志打印出执行的SQL为：

(D:/GoPath/src/gitlab.xinghuolive.com/HRMS/vermouth/model/user/test.go:45)

[2018-11-17 23:36:52] Error 1103: Incorrect table name ''

(D:/GoPath/src/gitlab.xinghuolive.com/HRMS/vermouth/model/user/test.go:45)

[2018-11-17 23:36:52] [8.97ms] SELECT * FROM ``

[0 rows affected or returned ]

&{ 0001-01-01 00:00:00 +0000 UTC {0001-01-01 00:00:00 +0000 UTC false} 0001-01-01 00:00:00 +0000 UTC 0001-01-01 00:00:00 +0000 UTC}

Exec()方法似乎不能很好地执行查询SQL，我们最好回到官方文档看看：

http://gorm.io/zh_CN/docs/sql_builder.html

官方给出的使用案例为：

db.Exec("DROP TABLE users;")

db.Exec("UPDATE orders SET shipped_at=? WHERE id IN (?)", time.Now(), []int64{11,22,33})

// Scan

type Result struct {

Name string

Age int

}

var result Result

db.Raw("SELECT name, age FROM users WHERE name = ?", 3).Scan(&result)

很明显可以看到，Exec()的语义应该是“执行某项数据库操作”，而查询SQL更倾向于使用Raw()。

（2019.3.17补充： Raw()方法之后必须跟上操作方法，比如Scan()方法，Raw()方法才能执行，否则看不到执行的SQL打印。而Exec()方法无论如何都会执行，在后面跟上一个Scan()方法也能实现查询效果）

（2）正确实践

正确地执行原生查询SQL：

func TestSelectUser(userID string, tx *gorm.DB) *table.User {

var user table.User

tx.Raw("SELECT * FROM user WHERE id = ?" , userID).Scan(&user)

return &user;

}

查询相当正常。

六、事务

（1）注意事务的一致性

假设存在以下流程：

INSERT User 到库中。
SELECT User，从而获取User中的entry_time字段。
如果获取不到User，报错“User Not Found”。
INSERT Operation 到库中，entry_time是其中的一个字段。

对应伪代码为：

// 开启事务

tx.Begin()

// 创建User，使用了事务链接

user.createUser(....., tx)

// 查询User，故意不使用事务

u := user.getUser(....., mysql.DB)

if u == nil {

return error

}

entry_time := u.EntryTime

// 创建Operation，使用了事务链接

operation.createOperation(....., entry_time, tx)

// 提交事务

tx.Commit()

如果我故意让getUser()脱离事务，会发生什么情况？

结果是，getUser()拿到的结果永远是nil，该流程永远无法完成。

为什么会发生这种情况？这是因为事务是具有隔离性的，createUser()是在事务进行插入操作，插入的结果（即这个User记录）只有在tx事务内才是可见的。因为getUser()没有使用tx事务，所以这个结果不可见，只能返回nil。

这个问题在事务处理中比较常见，如果不小心调用了一个没有使用事务的查询方法，就会一直得到空结果，比较隐蔽。

（2）事务中遇到panic

使用上文的伪代码，稍微改造一下：

// 开启事务

tx.Begin()

// 创建User，使用了事务链接

user.createUser(....., tx)

// 查询User，这次使用事务

u := user.getUser(....., mysql.DB)

// 删除判空操作

entry_time := u.EntryTime

// 创建Operation，使用了事务链接

operation.createOperation(....., entry_time, tx)

// 提交事务

tx.Commit()

这里我特意删除了判空操作，目的就是在事务中制造空指针panic。

如果真的出现了空指针panic，那么事务永远无法结束，出现死锁，整张表的写操作被锁定，只能进行读取。想要让事务结束，解决死锁，只能干掉执行事务的数据库链接，即重启所有正在跑的进程。

对于这个蛋疼问题，我们还是先看看关于事务的官方文档：

http://gorm.io/zh_CN/docs/transactions.html

官方示例为：

func CreateAnimals(db *gorm.DB) err {

// 注意：一旦开始事务的处理，请使用tx作为数据库处理器，而不是db

tx := db.Begin()

defer func() {

if r := recover(); r != nil {

tx.Rollback()

}

}()

if tx.Error != nil {

return err

}

if err := tx.Create(&Animal{Name: "Giraffe"}).Error; err != nil {

tx.Rollback()

return err

}

if err := tx.Create(&Animal{Name: "Lion"}).Error; err != nil {

tx.Rollback()

return err

}

return tx.Commit().Error

}

可以看见，最重要的部分就是defer：

defer func() {

if r := recover(); r != nil {

tx.Rollback()

}

}()

如果事务没有异常，那么肯定能正常commit()。

不管这个事务执行得如何，只要最后需要recover()，那就是需要回滚，直接Rollback()。

只要开始事务，就在后面跟一个defer处理，这固然是一个好习惯，但是平时经常写这么多事务相关的代码也很麻烦，万一写漏了就更糟糕了（比如忘记commit）。因此，完全可以封装一个事务执行方法。

下面是LJD大佬的代码：

// WithTransaction creates transaction and deals with rollbacks and commits.

func WithTransaction(f func(tx *gorm.DB) error) error {

tx := mysql.DB.Begin()

if tx.Error != nil {

return tx.Error

}

var err error

var success bool // 调用f时如果出现panic，err则会无法正常赋值，因此需要此变量

defer func() {

if !success {

tx.Rollback() // 执行f时出现任何问题，都要Rollback

}

}()

err = f(tx)

if err == nil {

success = true

return tx.Commit().Error // 成功则提交

}

return err

}

如果一路上都没有异常，那么一定能走到success = true，事务可以成功提交。
如果出现了异常，但是不是panic，可以被err = f(tx)捕获，但是不能进入err == nil，最后success依然是false，当前事务会Rollback()。
如果出现了panic，那么程序肯定无法正常执行下去，err = f(tx)甚至不能正常赋值。但是这时候success一直都是false，在defer中绝对能保证Rollback()，从而保护了数据的安全。

七、总结

说了这么多乱七八糟的错误示范，写完程序最好还是自己debug一遍，可以有效杜绝低级错误（有时候不这样干是因为懒，有时候是因为时间实在太赶）。

xie4ever

560

golang 个人使用GORM的一点教训

一、批量新增

（1）错误示范

（2）正确实践

二、删除

（1）错误示范

（2）正确实践

三、修改

（1）错误示范

（2）正确实践

四、查询

（1）错误示范

（2）正确实践

五、执行原生查询SQL

（1）错误示范

（2）正确实践

六、事务

（1）注意事务的一致性

（2）事务中遇到panic

七、总结

xie4ever

2 对 “golang 个人使用GORM的一点教训”的想法；

发表评论取消回复

一、批量新增

（1）错误示范

（2）正确实践

二、删除

（1）错误示范

（2）正确实践

三、修改

（1）错误示范

（2）正确实践

四、查询

（1）错误示范

（2）正确实践

五、执行原生查询SQL

（1）错误示范

（2）正确实践

六、事务

（1）注意事务的一致性

（2）事务中遇到panic

七、总结

xie4ever

2 对 “golang 个人使用GORM的一点教训”的想法；

发表评论 取消回复

发表评论取消回复