上期回顾
我会把Go语言中的知识点结合商业项目,让大家理论联络实践,融会贯通。
上一篇内容共享了【电商实战02】怎么借助工具快速生成代码?新手简单踩的这些坑一定要避开。
假如你第一次看我【电商实战】系列的文章,主张先看【电商实战系列】先看这儿:适合人群&课程大纲&开源地址&视频合集&一同学习
看过的朋友请疏忽,继续往下看:
本期要点
用到的知识点包含:
- ORM链式操作
- 怎么高雅的进行时刻保护
- 软删去和物理删去的差异
- 怎么高雅的完成软删去
- 结合商业项目需求,有哪些简单踩的坑?
本期内容除了在发布文章,也在B站发布了视频版。欢迎大家三连重视一波:# 【B站视频教程-电商实战03】链式操作_软删去_高雅的时刻管理_删去轮播图
下面要点介绍一下ORM链式操作-时刻保护的知识点,看完这部分再看视频作用更好。
ORM链式操作-时刻保护
需要留意,该特性仅对链式操作有效。
gdb
模块支撑对数据记载的写入、更新、删去时刻主动填充,进步开发保护效率。为了便于时刻字段称号、类型的统一保护,假如运用该特性,咱们约好:
-
字段应当设置允许值为
null
。 -
字段的类型有必要为时刻类型,如:
date
,datetime
,timestamp
。不支撑数字类型字段,如int
。 -
字段的称号不支撑自定义设置,而且固定称号约好为:
-
created_at
用于记载创立时更新,仅会写入一次。 -
updated_at
用于记载修正时更新,每次记载变更时更新。 -
deleted_at
用于记载的软删去特性,只有当记载删去时会写入一次。
字段称号其实不差异大小写,也会疏忽特殊字符,例如CreatedAt
,UpdatedAt
,DeletedAt
也是支撑的。此外,时刻字段称号能够经过装备文件进行自定义修正,并可运用TimeMaintainDisabled
装备完好关闭该特性,详细请参考ORM运用装备章节。
对时刻类型的固定其实是为了构成一种标准。
特性的启用
当数据表包含created_at
、updated_at
、deleted_at
恣意一个或多个字段时,该特性主动启用。
以下的示例中,咱们默认示例中的数据表均包含了这3个字段。
created_at
写入时刻
在履行Insert/InsertIgnore/BatchInsert/BatchInsertIgnore
办法时主动写入该时刻,随后坚持不变。
// INSERT INTO `user`(`name`,`created_at`,`updated_at`) VALUES('王中阳Go', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`)
g.Model("user").Data(g.Map{"name": "王中阳Go"}).Insert()
// INSERT IGNORE INTO `user`(`uid`,`name`,`created_at`,`updated_at`) VALUES(10000,'王中阳Go', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`)
g.Model("user").Data(g.Map{"uid": 10000, "name": "王中阳Go"}).InsertIgnore()
// REPLACE INTO `user`(`uid`,`name`,`created_at`,`updated_at`) VALUES(10000,'王中阳Go', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`)
g.Model("user").Data(g.Map{"uid": 10000, "name": "王中阳Go"}).Replace()
// INSERT INTO `user`(`uid`,`name`,`created_at`,`updated_at`) VALUES(10001,'王中阳Go', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`) ON DUPLICATE KEY UPDATE `uid`=VALUES(`uid`),`name`=VALUES(`name`),`updated_at`=VALUES(`updated_at`)
g.Model("user").Data(g.Map{"uid": 10001, "name": "王中阳Go"}).Save()
需要留意的是Replace
办法也会更新该字段,因为该操作相当于删去已存在的旧数据并从头写一条数据。
updated_at
更新时刻
在履行Insert/InsertIgnore/BatchInsert/BatchInsertIgnore
办法时主动写入该时刻,在履行Save/Update
时更新该时刻(留意当写入数据存在时会更新updated_at
时刻,不会更新created_at
时刻)。
// UPDATE `user` SET `name`='王中阳Go',`updated_at`='2020-06-06 21:00:00' WHERE name='王中阳Go'
g.Model("user").Data(g.Map{"name" : "王中阳Go"}).Where("name", "王中阳Go").Update()
// UPDATE `user` SET `status`=1,`updated_at`='2020-06-06 21:00:00' ORDER BY `login_time` asc LIMIT 10
g.Model("user").Data("status", 1).Order("login_time asc").Limit(10).Update()
// INSERT INTO `user`(`id`,`name`,`update_at`) VALUES(1,'王中阳Go','2020-12-29 20:16:14') ON DUPLICATE KEY UPDATE `id`=VALUES(`id`),`name`=VALUES(`name`),`update_at`=VALUES(`update_at`)
g.Model("user").Data(g.Map{"id": 1, "name": "王中阳Go"}).Save()
需要留意的是Replace
办法也会更新该字段,因为该操作相当于删去已存在的旧数据并从头写一条数据。
deleted_at
数据软删去
软删去会略微比较复杂一些,当软删去存在时,一切的查询句子都将会主动加上deleted_at
的条件。
// UPDATE `user` SET `deleted_at`='2020-06-06 21:00:00' WHERE uid=10
g.Model("user").Where("uid", 10).Delete()
查询的时候会产生一些变化,例如:
// SELECT * FROM `user` WHERE uid>1 AND `deleted_at` IS NULL
g.Model("user").Where("uid>?", 1).All()
能够看到当数据表中存在deleted_at
字段时,一切涉及到该表的查询操作都将主动加上deleted_at IS NULL
的条件
联表查询的场景
假如关联查询的几个表都启用了软删去特性时,会产生以下这种情况,即条件句子中会添加一切相关表的软删去时刻判断。
// SELECT * FROM `user` AS `u` LEFT JOIN `user_detail` AS `ud` ON (ud.uid=u.uid) WHERE u.uid=10 AND `u`.`deleted_at` IS NULL AND `ud`.`deleteat` IS NULL LIMIT 1
g.Model("user", "u").LeftJoin("user_detail", "ud", "ud.uid=u.uid").Where("u.uid", 10).One()
Unscoped
疏忽时刻特性
Unscoped
用于在链式操作中疏忽主动时刻更新特性,例如上面的示例,加上Unscoped
办法后:
// SELECT * FROM `user` WHERE uid>1
g.Model("user").Unscoped().Where("uid>?", 1).All()
// SELECT * FROM `user` AS `u` LEFT JOIN `user_detail` AS `ud` ON (ud.uid=u.uid) WHERE u.uid=10 LIMIT 1
g.Model("user", "u").LeftJoin("user_detail", "ud", "ud.uid=u.uid").Where("u.uid", 10).Unscoped().One()
软删去和物理删去的差异
- 软删去也叫符号删去,经过字段符号纪录是否被删去:
- 比方经过is_delete字段符号,默以为0,删去时设置为1
- 或许和视频内容一样,运用deleted_at字段纪录删去的时刻,默以为null
- 物理删去,便是直接将DB中的记载删掉
怎么高雅的完成软删去
假如你详细看完了ORM链式操作-时刻保护
这部分内容,想必心中一定有了答案。
结合商业项目需求,有哪些简单踩的坑?
- 结合实际情况决定运用物理删去还是软删去
- 比方管理后台删去轮播图这种操作主张运用软删去。因为或许出现误操作的情况,软删去能够及时找回;而且轮播图的数据往往不多,冗余保存也是没有问题的。
- 再比方用户移除保藏文章的记载,主张物理删去。原因是保藏文章,撤销保藏这类操作比较随意,没有任何风险。再者这类数据量比较巨大,软删去没有意义,反而会添加保藏操作的逻辑压力和DB压力。
本期内容除了在发布文章,也在B站发布了视频版。欢迎大家三连重视一波:# 【B站视频教程-电商实战03】链式操作_软删去_高雅的时刻管理_删去轮播图
一同学习
大众号:程序员升职加薪之旅
微信号:wangzhongyang1993
B站视频:王中阳Go
本文正在参加「金石方案 . 瓜分6万现金大奖」