?ORM鏈式操作-時間維護
需要注意，該特性僅對鏈式操作有效。
gdb模塊支持對數(shù)據(jù)記錄的寫入、更新、刪除時間自動填充，提高開發(fā)維護效率。為了便于時間字段名稱、類型的統(tǒng)一維護，如果使用該特性，我們約定：
- 字段應當設置允許值為null。
- 字段的類型必須為時間類型，如:date?, datetime?, timestamp?。不支持數(shù)字類型字段，如int。
- 字段的名稱不支持自定義設置，并且固定名稱約定為：
created_at用于保存記錄的創(chuàng)建時間，僅會寫入一次。
updated_at用于保存記錄的修改時間，每次記錄變更時更新。
deleted_at用于保存記錄的軟刪除特性，只有當記錄刪除時會寫入一次。
字段名稱其實不區(qū)分大小寫，也會忽略特殊字符，例如CreatedAt?, UpdatedAt?, DeletedAt?也是支持的。此外，時間字段名稱可以通過配置文件進行自定義修改，并可使用TimeMaintainDisabled配置完整關閉該特性，具體請參考 ORM使用配置 章節(jié)。
對時間類型的固定其實是為了形成一種規(guī)范。
特性的啟用
當數(shù)據(jù)表包含created_at、updated_at、deleted_at任意一個或多個字段時，該特性自動啟用。
以下的示例中，我們默認示例中的數(shù)據(jù)表均包含了這3個字段。
?created_at??寫入時間
在執(zhí)行Insert/InsertIgnore/BatchInsert/BatchInsertIgnore方法時自動寫入該時間，隨后保持不變。
// INSERT INTO `user`(`name`,`created_at`,`updated_at`) VALUES('john', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`)
g.Model("user").Data(g.Map{"name": "john"}).Insert()
// INSERT IGNORE INTO `user`(`uid`,`name`,`created_at`,`updated_at`) VALUES(10000,'john', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`)
g.Model("user").Data(g.Map{"uid": 10000, "name": "john"}).InsertIgnore()
// REPLACE INTO `user`(`uid`,`name`,`created_at`,`updated_at`) VALUES(10000,'john', `2020-06-06 21:00:00`, `2020-06-06 21:00:00`)
g.Model("user").Data(g.Map{"uid": 10000, "name": "john"}).Replace()
// INSERT INTO `user`(`uid`,`name`,`created_at`,`updated_at`) VALUES(10001,'john', `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": "john"}).Save()需要注意的是Replace方法也會更新該字段，因為該操作相當于刪除已存在的舊數(shù)據(jù)并重新寫一條數(shù)據(jù)。
?updated_at??更新時間
在執(zhí)行Insert/InsertIgnore/BatchInsert/BatchInsertIgnore?方法時自動寫入該時間，在執(zhí)行Save/Update?時更新該時間（注意當寫入數(shù)據(jù)存在時會更新updated_at?時間，不會更新created_at時間）。
// UPDATE `user` SET `name`='john guo',`updated_at`='2020-06-06 21:00:00' WHERE name='john'
g.Model("user").Data(g.Map{"name" : "john guo"}).Where("name", "john").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,'john guo','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": "john guo"}).Save()
需要注意的是Replace方法也會更新該字段，因為該操作相當于刪除已存在的舊數(shù)據(jù)并重新寫一條數(shù)據(jù)。
?deleted_at??數(shù)據(jù)軟刪除
軟刪除會稍微比較復雜一些，當軟刪除存在時，所有的查詢語句都將會自動加上deleted_at的條件。
// UPDATE `user` SET `deleted_at`='2020-06-06 21:00:00' WHERE uid=10
g.Model("user").Where("uid", 10).Delete()
查詢的時候會發(fā)生一些變化，例如：
// SELECT * FROM `user` WHERE uid>1 AND `deleted_at` IS NULL
g.Model("user").Where("uid>?", 1).All()
可以看到當數(shù)據(jù)表中存在deleted_at?字段時，所有涉及到該表的查詢操作都將自動加上deleted_at IS NULL的條件
聯(lián)表查詢的場景
如果關聯(lián)查詢的幾個表都啟用了軟刪除特性時，會發(fā)生以下這種情況，即條件語句中會增加所有相關表的軟刪除時間判斷。
// 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()
以上內(nèi)容來源自官方文檔：https://goframe.org/pages/viewpage.action?pageId=1114139
軟刪除和物理刪除的區(qū)別
- 軟刪除也叫標記刪除，通過字段標記DB中的紀錄是否被刪除：
比如通過is_delete字段標記，默認為0，刪除時設置為1
或者和視頻內(nèi)容一樣，使用deleted_at字段標記刪除的時間，默認為null
如何優(yōu)雅的實現(xiàn)軟刪除
如果你詳細看完了ORM鏈式操作-時間維護這部分內(nèi)容，想必心中一定有了答案。
結合商業(yè)項目需求，有哪些容易踩的坑？
一定要結合實際情況決定使用物理刪除還是軟刪除，下面的例子拋轉(zhuǎn)引玉：
1. 比如管理后臺刪除輪播圖這種操作建議使用軟刪除。因為可能出現(xiàn)誤操作的情況，軟刪除可以及時找回；而且輪播圖的數(shù)據(jù)往往不多，冗余保存也是沒有問題的。
2. 再比如用戶移除收藏文章的記錄，建議物理刪除。原因是收藏文章，取消收藏這類操作比較隨意，沒有任何風險。再者這類數(shù)據(jù)量比較龐大，軟刪除沒有意義，反而會增加收藏操作的邏輯壓力和DB壓力。
本文轉(zhuǎn)載自微信公眾號「 程序員升級打怪之旅」，作者「王中陽Go」，可以通過以下二維碼關注。
轉(zhuǎn)載本文請聯(lián)系「 程序員升級打怪之旅」公眾號。
