上期回顾

我会把Go语言中的知识点结合商业项目,让大家理论联络实践,融会贯通。

上一篇内容共享了【电商实战02】怎么借助工具快速生成代码?新手简单踩的这些坑一定要避开。

假如你第一次看我【电商实战】系列的文章,主张先看【电商实战系列】先看这儿:适合人群&课程大纲&开源地址&视频合集&一同学习

看过的朋友请疏忽,继续往下看:

本期要点

用到的知识点包含:

  1. ORM链式操作
  2. 怎么高雅的进行时刻保护
  3. 软删去和物理删去的差异
  4. 怎么高雅的完成软删去
  5. 结合商业项目需求,有哪些简单踩的坑?

本期内容除了在发布文章,也在B站发布了视频版。欢迎大家三连重视一波:# 【B站视频教程-电商实战03】链式操作_软删去_高雅的时刻管理_删去轮播图

下面要点介绍一下ORM链式操作-时刻保护的知识点,看完这部分再看视频作用更好。

ORM链式操作-时刻保护

需要留意,该特性仅对链式操作有效。

gdb模块支撑对数据记载的写入、更新、删去时刻主动填充,进步开发保护效率。为了便于时刻字段称号、类型的统一保护,假如运用该特性,咱们约好:

  • 字段应当设置允许值为null

  • 字段的类型有必要为时刻类型,如:date,datetime,timestamp。不支撑数字类型字段,如int

  • 字段的称号不支撑自定义设置,而且固定称号约好为:

  • created_at用于记载创立时更新,仅会写入一次。

  • updated_at用于记载修正时更新,每次记载变更时更新。

  • deleted_at用于记载的软删去特性,只有当记载删去时会写入一次。

字段称号其实不差异大小写,也会疏忽特殊字符,例如CreatedAt,UpdatedAt,DeletedAt也是支撑的。此外,时刻字段称号能够经过装备文件进行自定义修正,并可运用TimeMaintainDisabled装备完好关闭该特性,详细请参考ORM运用装备章节。

对时刻类型的固定其实是为了构成一种标准。

特性的启用

当数据表包含created_atupdated_atdeleted_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()

软删去和物理删去的差异

  1. 软删去也叫符号删去,经过字段符号纪录是否被删去:
  • 比方经过is_delete字段符号,默以为0,删去时设置为1
  • 或许和视频内容一样,运用deleted_at字段纪录删去的时刻,默以为null
  1. 物理删去,便是直接将DB中的记载删掉

怎么高雅的完成软删去

假如你详细看完了ORM链式操作-时刻保护这部分内容,想必心中一定有了答案。

结合商业项目需求,有哪些简单踩的坑?

  1. 结合实际情况决定运用物理删去还是软删去
  2. 比方管理后台删去轮播图这种操作主张运用软删去。因为或许出现误操作的情况,软删去能够及时找回;而且轮播图的数据往往不多,冗余保存也是没有问题的。
  3. 再比方用户移除保藏文章的记载,主张物理删去。原因是保藏文章,撤销保藏这类操作比较随意,没有任何风险。再者这类数据量比较巨大,软删去没有意义,反而会添加保藏操作的逻辑压力和DB压力。

本期内容除了在发布文章,也在B站发布了视频版。欢迎大家三连重视一波:# 【B站视频教程-电商实战03】链式操作_软删去_高雅的时刻管理_删去轮播图

一同学习

【电商实战03】如何使用ORM链式操作?如何优雅的实现软删除?

大众号:程序员升职加薪之旅

微信号:wangzhongyang1993

B站视频:王中阳Go

本文正在参加「金石方案 . 瓜分6万现金大奖」