快捷導(dǎo)航

Python ORM框架SQLAlchemy學(xué)習(xí)筆記之?dāng)?shù)據(jù)添加和事務(wù)回滾介紹

更新時間：2014年06月10日 10:52:11 作者：

這篇文章主要介紹了Python ORM框架SQLAlchemy學(xué)習(xí)筆記之?dāng)?shù)據(jù)添加和事務(wù)回滾介紹,需要的朋友可以參考下

1. 添加一個新對象

前面介紹了映射到實體表的映射類User，如果我們想將其持久化(Persist)，那么就需要將這個由User類建立的對象實例添加到我們先前創(chuàng)建的Session會話實例中：

ed_user = User('ed', 'Ed Jones', 'edspassword')
session.add(ed_user)

上面兩段代碼執(zhí)行完后對象持久化了么？你或許會興沖沖的跑去數(shù)據(jù)庫里查看，結(jié)果卻失望而歸——數(shù)據(jù)庫里什么都沒有。為什么呢？因為SQLAlchemy采取的是Lazyload策略，也就是說現(xiàn)在這個對象被標(biāo)記為Pending準(zhǔn)備狀態(tài)，但沒有執(zhí)行任何可能導(dǎo)致數(shù)據(jù)庫變化的SQL語句。那么什么時候會執(zhí)行SQL語句并真正持久化呢？這個要等SQLAlchemy覺得需要的時候，比如我們現(xiàn)在查詢這個對象、對象的一個屬性或者顯式的調(diào)用flush方法，這時候SQLAlchemy覺得它“是時候”或者“不得不”執(zhí)行SQL數(shù)據(jù)庫查詢以便于把標(biāo)記為Pending的數(shù)據(jù)寫入數(shù)據(jù)庫表中了。假如這時候你執(zhí)行的獲取對象、對象屬性或者類似的操作，SQLAlchemy在執(zhí)行完SQL語句后會將你所要查詢的數(shù)據(jù)反饋給你。

為了更好的說明這一點，這里舉一個例子，這里涉及到我們第一個查詢示例，我們調(diào)用了Query對象來幫助我們完成這些，比如這里我們獲取剛剛持久化的用戶ed，我們通過“過濾(filter by)”的方式來查詢用戶名為ed的用戶，當(dāng)然我們只需要一個ed，假如有多個重名的ed的話，查詢將會返回所有叫ed的記錄集列表，我們就選擇第一個ed吧(first)。

復(fù)制代碼代碼如下:

>>> our_user = session.query(User).filter_by(name='ed').first() 
BEGIN (implicit)
INSERT INTO users (name, fullname, password) VALUES (?, ?, ?)
('ed', 'Ed Jones', 'edspassword')
SELECT users.id AS users_id,
        users.name AS users_name,
        users.fullname AS users_fullname,
        users.password AS users_password
FROM users
WHERE users.name = ?
 LIMIT ? OFFSET ?
('ed', 1, 0)
>>> our_user
<User('ed','Ed Jones', 'edspassword')>

可以看到上面的查詢語句返回了一個User的實例，而這個實例恰恰是我們先前持久化的。同時由于我們指定了引擎的echo=True，所以再執(zhí)行查詢時輸出了SQL語句，我們注意到除了普通的SELECT外，還有額外的INSERT語句，而INSERT處理的就是我們剛剛通過session.add()持久化標(biāo)記為Pending的對象，也就是說你在實際操作持久化數(shù)據(jù)時才會由延遲加載(lazyload)真正觸發(fā)數(shù)據(jù)庫操作。

實際上Session查詢反饋給我們的User對象和我們剛剛持久化的對象是同一個對象，通過下面的代碼可以檢驗：

復(fù)制代碼代碼如下:

>>> ed_user is our_user
True

實際上這里ORM的操作概念有點類似于標(biāo)識映射(identity map)，也就是說在實體數(shù)據(jù)庫之前架設(shè)一張標(biāo)識映射表，可以看作緩存表的一種，任何存儲數(shù)據(jù)庫的對象會事先停留在這張表上，如果我們要查詢一個對象，將事先查詢這張標(biāo)識映射表，如果這個對象存在則直接取出，否則就會查詢實體數(shù)據(jù)庫，我覺得這個有點像緩存的作用，可以這么理解吧。

一旦一個帶有獨一無二的主鍵的對象被Session持久化了，所有使用該主鍵在同一Session上查詢的對象將是同一個Python對象。當(dāng)然對于在這個會話中持久化另外一個具有相同主鍵的對象將會拋出異常錯誤（主鍵不能重復(fù)）。

如果我們想一次性添加多個對象到Session中可以調(diào)用add_all()：

復(fù)制代碼代碼如下:

>>> session.add_all([
...     User('wendy', 'Wendy Williams', 'foobar'),
...     User('mary', 'Mary Contrary', 'xxg527'),
...     User('fred', 'Fred Flinstone', 'blah')])

下面再談?wù)勑薷?，假如Ed覺得他的密碼不太安全，決定修改，可以直接這么做：

復(fù)制代碼代碼如下:

>>> ed_user.password = 'f8s7ccs'

同樣的道理，這個改動不會立即反映到數(shù)據(jù)庫里，當(dāng)然Session意識到你要修改Ed的密碼，它會暫時緩沖這個改動，我們可以通過dirty方法了解到我們的改動：

復(fù)制代碼代碼如下:

>>> session.dirty
IdentitySet([<User('ed','Ed Jones', 'f8s7ccs')>])

同樣的我們可以通過new方法“窺看”到先前用add_all()持久化的對象列表：

復(fù)制代碼代碼如下:

>>> session.new  
IdentitySet([<User('wendy','Wendy Williams', 'foobar')>,
<User('mary','Mary Contrary', 'xxg527')>,
<User('fred','Fred Flinstone', 'blah')>])

當(dāng)然這些改動都沒有真正反饋到數(shù)據(jù)庫里，相當(dāng)于都被ORM緩沖了。接下來我們可以顯式的調(diào)用commit()來告訴Session：“我們目前就添加或者改動這么多可以提交數(shù)據(jù)庫了”：

復(fù)制代碼代碼如下:

>>> session.commit()
UPDATE users SET password=? WHERE users.id = ?
('f8s7ccs', 1)
INSERT INTO users (name, fullname, password) VALUES (?, ?, ?)
('wendy', 'Wendy Williams', 'foobar')
INSERT INTO users (name, fullname, password) VALUES (?, ?, ?)
('mary', 'Mary Contrary', 'xxg527')
INSERT INTO users (name, fullname, password) VALUES (?, ?, ?)
('fred', 'Fred Flinstone', 'blah')
COMMIT

于是剛才緩沖的數(shù)據(jù)或者變更全部被作為事務(wù)一次性flush到數(shù)據(jù)庫了，通過輸出的SQL語句我們也可以看出來。

這個操作完成后被會話(Session)引用的數(shù)據(jù)庫連接資源將被回收到連接池中，接下來的對于這個Session的任何操作將會觸發(fā)一個新的事務(wù)(Transaction)，當(dāng)然會再次和連接池申請獲得數(shù)據(jù)庫連接資源。

之前文章介紹到Ed的User對象的id為None，現(xiàn)在讓我們來看看吧：

復(fù)制代碼代碼如下:

>>> ed_user.id 
BEGIN (implicit)
SELECT users.id AS users_id,
        users.name AS users_name,
        users.fullname AS users_fullname,
        users.password AS users_password
FROM users
WHERE users.id = ?
(1,)
1

除了由于echo=True導(dǎo)致輸出的SQL語句，看看是不是有了值，值為1。

無論是立即(commit、flush)或者通過“首次訪問加載(load-on-first-access)”，在Session在數(shù)據(jù)庫插入一條新記錄后，所有新生成的標(biāo)識和數(shù)據(jù)庫生成的默認(rèn)值對于實例來說才可以被訪問到。

當(dāng)調(diào)用了commit()以后，SQLAlchemy將會刷新當(dāng)前事務(wù)的所有數(shù)據(jù)到數(shù)據(jù)庫里。

2. 事務(wù)回滾

本文以及同系列的文章是以自己的想法翻譯的，不當(dāng)之處還請指正，不做權(quán)威依據(jù)。好了，下面我還是簡單介紹一下事務(wù)回滾吧，其實這個和數(shù)據(jù)庫的事務(wù)回滾一個意思，就是我們做錯事后要撤消之前的變更。

因為Session是作為事務(wù)(transaction)來工作的，所以我們可以回滾(roll back)先前所做的更改。接下來讓我們做兩個稍后會被撤銷(回滾)的更改，第一個是修改ed_user.name：

復(fù)制代碼代碼如下:

>>> ed_user.name = 'Edwardo'

第二個是增加一個“不期望”的用戶fake_user：

復(fù)制代碼代碼如下:

>>> fake_user = User('fakeuser', 'Invalid', '12345')
>>> session.add(fake_user)

查詢當(dāng)前會話，我們可以看到這兩個變更已經(jīng)被flush到當(dāng)前事務(wù)里了：

復(fù)制代碼代碼如下:

>>> session.query(User).filter(User.name.in_(['Edwardo', 'fakeuser'])).all() 
UPDATE users SET name=? WHERE users.id = ?
('Edwardo', 1)
INSERT INTO users (name, fullname, password) VALUES (?, ?, ?)
('fakeuser', 'Invalid', '12345')
SELECT users.id AS users_id,
        users.name AS users_name,
        users.fullname AS users_fullname,
        users.password AS users_password
FROM users
WHERE users.name IN (?, ?)
('Edwardo', 'fakeuser')
[<User('Edwardo','Ed Jones', 'f8s7ccs')>, <User('fakeuser','Invalid', '12345')>]

好吧，接下來是見證奇跡的時刻，我們回滾(rolling back)事務(wù)：

復(fù)制代碼代碼如下:

>>> session.rollback()
ROLLBACK
>>> ed_user.name 
BEGIN (implicit)
SELECT users.id AS users_id,
        users.name AS users_name,
        users.fullname AS users_fullname,
        users.password AS users_password
FROM users
WHERE users.id = ?
(1,)
u'ed'
>>> fake_user in session
False

我們可以看到ed_user的名字變回ed，并且我們不期望的用戶fake_user被“踢出”會話(Session)了。

最后，我們可以查詢一下用戶名在['ed', 'fakeuser']范圍的用戶，確保我們的更改是有效的：

復(fù)制代碼代碼如下:

>>> session.query(User).filter(User.name.in_(['ed', 'fakeuser'])).all()
SELECT users.id AS users_id,
        users.name AS users_name,
        users.fullname AS users_fullname,
        users.password AS users_password
FROM users
WHERE users.name IN (?, ?)
('ed', 'fakeuser')
[<User('ed','Ed Jones', 'f8s7ccs')>]

好了，今天就到這里，今天我們講解了添加對象和事務(wù)回滾，或多或少穿插了些簡單的查詢，接下來我們會介紹較為復(fù)雜一些的查詢語句，敬請期待！

您可能感興趣的文章: