如標(biāo)題所說，本文的目標(biāo)十分明確，就是為irmin這個(gè)數(shù)據(jù)庫實(shí)現(xiàn)一個(gè)簡單的odm，至于為什么是odm，主要還是該數(shù)據(jù)庫的存儲(chǔ)機(jī)制類似文本數(shù)據(jù)庫，故而是odm，而非orm或者ogm

首先，我們期望項(xiàng)目盡可能不要使用rust以外的語言，故而這里我們使用irmin自帶的graphql api，然后在上層編寫類似odm的操作

那么，首先創(chuàng)建一個(gè)rust項(xiàng)目（建議將項(xiàng)目創(chuàng)建在我們整個(gè)系列的workspace里面，以方便后續(xù)的其他項(xiàng)目調(diào)用）

首先，引入三個(gè)依賴，graphql和任意一個(gè)靠譜的http client（你可以選擇reqwest或者surf）以及該http client依賴的異步環(huán)境（注意，如果使用的是surf可以不引入異步運(yùn)行時(shí)，此時(shí)將直接同步運(yùn)行，surf默認(rèn)使用curl client，可以自行修改為hyper來兼容tokio，具體的可以看這個(gè)庫的feature flag）

首先我們這里選擇graphql client這個(gè)庫作為我們處理graphql的庫，該庫在最近的版本提供了同樣的接口以便你使用某個(gè)http client使用而非一如既往的默認(rèn)使用reqwest（reqwest真的沒有那么好）

graphql-client庫提供了一套cli來輔助開發(fā)，

安裝完以后，

首先我們需要啟動(dòng)irmin的graphql服務(wù)器，不知道怎么啟動(dòng)的可以回看上一章，然后獲取服務(wù)器的schema到本地用于后續(xù)生成客戶端代碼

此時(shí)我們會(huì)獲得一個(gè)json schema（需要sdl版本的schema的則需要自行轉(zhuǎn)換，但在此處schema本身并不重要）

在開始使用graphql client生成請求代碼之前，我們先來完成數(shù)據(jù)管理方面的功能，

首先irmin的數(shù)據(jù)存儲(chǔ)是有路徑的，數(shù)據(jù)本身可以用json存儲(chǔ)亦或是直接使用字符串，鑒于上一章我們已經(jīng)規(guī)定了存儲(chǔ)使用json，那么我們的存儲(chǔ)方案自然也是基于json的，這一點(diǎn)有點(diǎn)類似與arangodb，但我們這個(gè)是純粹的文本數(shù)據(jù)庫，arangodb支持圖操作（當(dāng)然這些都是題外話了）

那么我們可以做一些最基本的規(guī)定，例如，我們的數(shù)據(jù)將以path為{collection_name}/{one_unique_id}的格式進(jìn)行存儲(chǔ)，該方式類似于傳統(tǒng)數(shù)據(jù)庫的表，不過鑒于分布式原因需要一個(gè)解決id沖突的方案，這里我們是類git的數(shù)據(jù)庫，我們完全可以直接用commit的hash值來作為id，但commit發(fā)生在提交之后，故而無法直接使用該hash值，我們只能不得已使用Snowflake算法，由于rust社區(qū)并沒有什么久負(fù)盛名的實(shí)現(xiàn)，故而這里在crates.io上隨便找了一個(gè)，各位如果有更好的選擇可以告知在下，感激不盡

那么，我們來思考一下我們這個(gè)項(xiàng)目的結(jié)構(gòu)（這里我們用最簡單的方式來設(shè)計(jì)，如果你喜歡高度抽象的項(xiàng)目，你可以選擇java，c#等認(rèn)為抽象就是好的語言），首先是核心功能為將用戶的操作轉(zhuǎn)變?yōu)閷?duì)graphql api的調(diào)用，并將graphql api的回執(zhí)反饋給用戶，這過程中，我們需要處理用戶的操作，處理graphql api可能返回的錯(cuò)誤

那么，我們先來處理用戶的操作，這里可以有多種選擇，一種是提供一種類似于Model的東西給到用戶，另一種則是提供一個(gè)query manager，前者可以適當(dāng)保證表結(jié)構(gòu)，后者則更符合文本數(shù)據(jù)庫的使用習(xí)慣，但不管如何，引入serde和serde_json是必要的

然后如果我們選擇第一種方式，那么就需要定義一個(gè)Model trait，如果技術(shù)條件允許的情況下還需要提供proc_macro的支持（這樣就可以給用戶derive一鍵式的體驗(yàn)，不然用戶需要實(shí)現(xiàn)的東西太多，影響體驗(yàn)）

那么如何編寫這個(gè)proc macro呢？如果沒有看過相關(guān)教程的建議先學(xué)習(xí)一下proc macro的相關(guān)知識(shí)，如果只希望簡單的過一下可以看這里

那么我們的目標(biāo)就是為某些類型實(shí)現(xiàn)該trait，看起來很復(fù)雜，但是我們可以一步一步來實(shí)現(xiàn)，首先，我們需要為被derive的類型實(shí)現(xiàn)兩個(gè)子類型，即QueryParams和UpdateParams，這兩個(gè)類型主要為后續(xù)的查找和更新函數(shù)服務(wù)，之所以給出這兩個(gè)類型，主要原因是查找時(shí)可能會(huì)較填寫時(shí)更復(fù)雜，多了一層操作符（大于小于之類的東西），而更新時(shí)則不必所有數(shù)據(jù)都填寫，故而會(huì)將一部分必填數(shù)據(jù)的修改參數(shù)變?yōu)镺ption類型（查找時(shí)同理）

等等？貌似要為irmin實(shí)現(xiàn)query operator需要自定義數(shù)據(jù)庫，可能需要自行編寫一個(gè)wrapper在該數(shù)據(jù)庫上層解決復(fù)雜查詢的問題，怎么一開始沒有想到呢？這就有點(diǎn)尷尬了，現(xiàn)在看到這個(gè)operator才想起來

那么，只能另尋一個(gè)數(shù)據(jù)庫解決方案了，但irmin在下依舊會(huì)學(xué)習(xí)（放棄在該系列使用只是因?yàn)閷W(xué)習(xí)時(shí)間可能會(huì)很長，由于是rust以外的問題，不能成為拖延該系列的理由）

目前的想法是使用一種分布式架構(gòu)，在多個(gè)數(shù)據(jù)庫的上層提供一層統(tǒng)一的api，所有服務(wù)的數(shù)據(jù)訪問均通過該api，由該api來分配數(shù)據(jù)查詢?nèi)蝿?wù)，下層數(shù)據(jù)庫根據(jù)需求自行選擇并各自提供合適的api給到上層的api gateway（話說搞這么大真的合適嗎，就一個(gè)demo）