1. 創(chuàng)建映射類的實例(Instance)

前面介紹了如何將數(shù)據(jù)庫實體表映射到Python類上，下面我們可以創(chuàng)建這個類的一個實例(Instance)，我們還是以前一篇文章的User類為例，讓我們創(chuàng)建User對象：

和普通的Python類一樣實例化，大家可能會問為什么ed_user.id會是None值，首先id這個屬性沒有通過__init__()構(gòu)造方法初始化，所以默認會因為先前定義的ORM的id列(Column)而產(chǎn)生一個None值，在默認情況下，ORM會為所有被映射的表列創(chuàng)建類屬性，這些屬性是通過Python語言中描述符(Descriptors)機制來實現(xiàn)的。所以這些屬性的使用會包含一些額外的行為，包括跟蹤修改，或者當需要時自動從數(shù)據(jù)庫加載新的數(shù)據(jù)，也就是說我們在使用這些屬性時，包括修改或者讀取，都會觸發(fā)ORM內(nèi)部的一系列動作。

等等，你還沒有說明白為什么id這個屬性會為None值呢。呵呵，其實我們現(xiàn)在并沒有將數(shù)據(jù)插入數(shù)據(jù)庫，一般主鍵這個屬性會在插入數(shù)據(jù)庫時自動產(chǎn)生一個不重復的值以保證唯一性。由于我們沒有對對象實行持久化(Persist) (所謂的持久化就是把對象數(shù)據(jù)按照映射關系存儲入數(shù)據(jù)庫里) 所以這里id值為None。別著急，稍后當我們介紹將數(shù)據(jù)持久化后你就可以看到一個新的自動產(chǎn)生的id了。

接下來小偷懶一下，介紹一個偷懶的技巧:-)

假如我們不定義映射類的構(gòu)造方法__init__()會帶來什么不良影響嗎？完全不會，SQLAlchemy為我們考慮到這點，假如我們偷懶將先前的User類定義成這樣：

由于User繼承自Base (Base定義見上一篇文章)，所以受到Declarative系統(tǒng)的管理，Declarative系統(tǒng)發(fā)現(xiàn)這個類缺少構(gòu)造方法，于是很友善的給我們補上了一個構(gòu)造方法，當然其提供的構(gòu)造方法則不能像我們自己定義的構(gòu)造方法那樣使用基于位置的參數(shù)訪問，建議使用基于鍵的參數(shù)訪問方式，包括我們所有用Column定義映射的列，比如如下方式：

id也可以傳入，通常意義上這類主鍵由系統(tǒng)自動維護，我們無需為其賦值。

2. 創(chuàng)建并使用會話(Session)

到這里可謂是“萬事俱備，只欠東風了”，用官方文檔的話說“我們現(xiàn)在已經(jīng)準備好和數(shù)據(jù)庫‘交談'了” (We're now ready to start talking to the database)。ORM的操作句柄(Handle)被稱為會話(Session)。為了使用會話，我們需要先配置它，配置Session的代碼語句應該和create_engine()創(chuàng)建引擎的代碼語句在一個代碼級別上(放在一起就行了)。

比如我們利用create_engine()先建立起引擎名字為engine（關于引擎的建立代碼可以參考我第一篇文章），然后利用sessionmaker()工廠函數(shù)建立起Session類，同時綁定我們現(xiàn)有的引擎，比如代碼如下：

假如我們創(chuàng)建Session的代碼與創(chuàng)建引擎的代碼不在一個級別上呢，比如先sessionmaker()一個Session類，然后才用create_engine()創(chuàng)建了引擎，那么我們還有機會將Session和引擎綁定到一起嗎？當然可以，我們可以利用Session類的configure方法來配置引擎綁定，比如這樣的：

到這里通過sessionmaker()工廠創(chuàng)造出的Session類應該綁定了我們先前創(chuàng)建的Engine了，但是會話還沒有真正開始，要開始會話我們需要實例化這個Session類：

到這里session就獲取了由Engine維護的數(shù)據(jù)庫連接池，并且會維持內(nèi)存中的映射數(shù)據(jù)直到提交(commit)更改或者關閉會話對象。

到這里會話的建立就講解完了，接下來會講解真正的ORM數(shù)據(jù)庫查詢部分，歡迎關注！

最新評論