Python数据库ORM SQLAlchemy 0.7学习笔记(4) 添加对象

提醒：本页面将不再更新、维护或者支持，文章、评论所叙述内容存在时效性，涉及技术细节或者软件使用方面不保证能够完全有效可操作，请谨慎参考！

1. 添加一个新对象

前面介绍了映射到实体表的映射类 User ，如果我们想将其持久化(Persist)，那么就需要将这个由 User 类建立的对象实例添加到我们先前创建的Session会话实例中：

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

上面两段代码执行完后对象持久化了么？你或许会兴冲冲的跑去数据库里查看，结果却失望而归——数据库里什么都没有。为什么呢？因为SQLAlchemy采取的是Lazyload策略，也就是说现在这个对象被标记为Pending准备状态，但没有执行任何可能导致数据库变化的SQL语句。那么什么时候会执行SQL语句并真正持久化呢？这个要等SQLAlchemy觉得需要的时候，比如我们现在查询这个对象、对象的一个属性或者显式的调用 flush 方法，这时候SQLAlchemy觉得它“是时候”或者“不得不”执行SQL数据库查询以便于把标记为Pending的数据写入数据库表中了。假如这时候你执行的获取对象、对象属性或者类似的操作，SQLAlchemy在执行完SQL语句后会将你所要查询的数据反馈给你。

为了更好的说明这一点，这里举一个例子，这里涉及到我们第一个查询示例，我们调用了Query对象来帮助我们完成这些，比如这里我们获取刚刚持久化的用户ed，我们通过“过滤(filter by)”的方式来查询用户名为ed的用户，当然我们只需要一个ed，假如有多个重名的ed的话，查询将会返回所有叫ed的记录集列表，我们就选择第一个ed吧(first)。

>>> 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 ，所以再执行查询时输出了SQL语句，我们注意到除了普通的 SELECT 外，还有额外的 INSERT 语句，而 INSERT 处理的就是我们刚刚通过 session.add() 持久化标记为Pending的对象，也就是说你在实际操作持久化数据时才会由延迟加载(lazyload)真正触发数据库操作。

实际上 Session 查询反馈给我们的 User 对象和我们刚刚持久化的对象是同一个对象，通过下面的代码可以检验：

>>> ed_user is our_user
True

实际上这里ORM的操作概念有点类似于标识映射(identity map) ，也就是说在实体数据库之前架设一张标识映射表，可以看作缓存表的一种，任何存储数据库的对象会事先停留在这张表上，如果我们要查询一个对象，将事先查询这张标识映射表，如果这个对象存在则直接取出，否则就会查询实体数据库，我觉得这个有点像缓存的作用，可以这么理解吧。

一旦一个带有独一无二的主键的对象被 Session 持久化了，所有使用该主键在同一 Session 上查询的对象将是同一个Python对象。当然对于在这个会话中持久化另外一个具有相同主键的对象将会抛出异常错误（主键不能重复）。

如果我们想一次性添加多个对象到 Session 中可以调用 add_all() ：

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

下面再谈谈修改，假如Ed觉得他的密码不太安全，决定修改，可以直接这么做：

>>> ed_user.password = 'f8s7ccs'

同样的道理，这个改动不会立即反映到数据库里，当然 Session 意识到你要修改Ed的密码，它会暂时缓冲这个改动，我们可以通过 dirty 方法了解到我们的改动：

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

同样的我们可以通过 new 方法“窥看”到先前用 add_all() 持久化的对象列表：

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

当然这些改动都没有真正反馈到数据库里，相当于都被ORM缓冲了。接下来我们可以显式的调用 commit() 来告诉 Session ：“我们目前就添加或者改动这么多可以提交数据库了”：

>>> 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

于是刚才缓冲的数据或者变更全部被作为事务一次性flush到数据库了，通过输出的SQL语句我们也可以看出来。

这个操作完成后被会话(Session)引用的数据库连接资源将被回收到连接池中，接下来的对于这个 Session 的任何操作将会触发一个新的事务(Transaction)，当然会再次和连接池申请获得数据库连接资源。

之前文章介绍到Ed的 User 对象的 id 为 None ，现在让我们来看看吧：

>>> 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 导致输出的SQL语句，看看是不是有了值，值为1。

无论是立即( commit 、 flush )或者通过“首次访问加载(load-on-first-access)”，在 Session 在数据库插入一条新记录后，所有新生成的标识和数据库生成的默认值对于实例来说才可以被访问到。

当调用了 commit() 以后，SQLAlchemy将会刷新当前事务的所有数据到数据库里。

2. 事务回滚

本文以及同系列的文章是以自己的想法翻译的，不当之处还请指正， 不做权威依据 。好了，下面我还是简单介绍一下事务回滚吧，其实这个和数据库的事务回滚一个意思，就是我们做错事后要撤消之前的变更。

因为 Session 是作为事务(transaction)来工作的，所以我们可以回滚(roll back)先前所做的更改。接下来让我们做两个稍后会被撤销(回滚)的更改，第一个是修改 ed_user.name ：

>>> ed_user.name = 'Edwardo'

第二个是增加一个“不期望”的用户 fake_user ：

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

查询当前会话，我们可以看到这两个变更已经被flush到当前事务里了：

>>> 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)事务：

>>> 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'] 范围的用户，确保我们的更改是有效的：

>>> 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')>]

好了，今天就到这里，今天我们讲解了添加对象和事务回滚，或多或少穿插了些简单的查询，接下来我们会介绍较为复杂一些的查询语句，敬请期待！