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

本文主要是介绍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)，也就是说在实体数据库之前架设一张标识映射表，可以看作缓存表的一种，任何存储数据库的对象会事先停留在这张表上，如果我们要查询一个对象，将事先查询这张标识映射表，如果这个对象存在则直接取出，否则就会查询实体数据库，我觉得这个有点像缓存的作用，可以这么理解吧。

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