一旦一个带有独一无二的主键的对象被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。
