SqlAlchemy 2.0 中文文档(六十三)(3)https://developer.aliyun.com/article/1560863
1.0.5
发布日期:2015 年 6 月 7 日
orm
- [orm] [feature]
添加了新的事件InstanceEvents.refresh_flush()
,在刷新过程中调用 INSERT 或 UPDATE 级别的默认值通过 RETURNING 或 Python 端的默认值调用时触发。这是为了提供一个钩子,不再像#3167那样在刷新过程中不再调用属性和验证事件。
参考:#3427 - [orm] [bug]
当Query
返回行时使用的“轻量级命名元组”未正确实现__slots__
,以至于它仍然有一个__dict__
。这个问题已经解决,但是在极端情况下,如果有人给返回的元组分配值,那么将不再起作用。
参考:#3420
engine
- [engine] [feature]
添加了新的引擎事件ConnectionEvents.engine_disposed()
。在调用Engine.dispose()
方法后调用。 - [engine] [feature]
对引擎插件钩子进行调整,使得当使用方言插件时,URL.get_dialect()
方法将继续返回最终的Dialect
对象,而不需要调用者知道Dialect.get_dialect_cls()
方法。
参考:#3379 - [engine] [bug]
修复已知布尔值在engine_from_config()
中使用时未被正确解析的错误;这些包括pool_threadlocal
和 psycopg2 参数use_native_unicode
。
参考:#3435 - [engine] [bug]
添加了对表现不当的 DBAPI 情况的支持,该情况下 pep-249 异常名称与完全不同名称的异常类相关联,阻止 SQLAlchemy 自己的异常包装正确包装错误。使用的 SQLAlchemy 方言需要实现一个新的访问器DefaultDialect.dbapi_exception_translation_map
来支持此功能;现在为 py-postgresql 方言实现了此功能。
参考:#3421 - [engine] [bug]
修复了一个 bug,涉及当使用池检出事件处理程序并在处理程序本身中进行连接尝试但失败时,拥有连接记录直到连接错误本身的堆栈跟踪被释放才会被释放的情况。对于仅使用单个连接的测试池的情况,这意味着池将被完全检出,直到该堆栈跟踪被释放。这主要影响非常具体的调试场景,并且在任何生产应用程序中都不太可能引起注意。修复方法是在重新引发捕获的异常之前显式检入记录。
参考:#3419
sql
- [sql] [feature]
官方添加了对Insert.from_select()
中的 SELECT 使用的 CTE 的支持。此行为直到 0.9.9 时偶然有效,当时由于与 #3248 的不相关更改而不再有效。请注意,这是在 INSERT 之后 SELECT 之前呈现 WITH 子句的方式;在 INSERT、UPDATE、DELETE 的顶层呈现 CTE 的全部功能是针对稍后发布的新功能。
此更改还被反向移植至:0.9.10
参考:#3418
postgresql
- [postgresql] [bug] [pypy]
修复了与 pypy psycopg2cffi 方言相关的一些打字和测试问题,特别是当前的 2.7.0 版本不支持 JSONB 类型。对于 psycopg2 功能的版本检测已调整为 psycopg2cffi 的特定子版本。此外,已启用了对 psycopg2cffi 下所有 psycopg2 功能系列的测试覆盖。
参考:#3439
mssql
- [mssql] [bug]
向 MSSQL 方言添加了一个新的方言标志legacy_schema_aliasing
,当设置为 False 时,将禁用非常古老和过时的行为,即编译器试图将所有模式限定的表名转换为别名,以解决旧问题和不再可定位的问题,其中 SQL Server 无法在所有情况下解析多部分标识符名称。此行为阻止更复杂的语句正确工作,包括使用提示的语句,以及嵌入相关 SELECT 语句的 CRUD 语句。与其继续修复功能以使其与更复杂的语句一起工作,不如将其禁用,因为对于任何现代 SQL Server 版本都不应再需要它。对于 1.0.x 系列,该标志默认为 True,保持当前行为不变。在 1.1 系列中,默认为 False。对于 1.0 系列,当未显式设置为任何值时,将在语句中首次使用模式限定的表时发出警告,建议为所有现代 SQL Server 版本设置该标志为 False。
请参见
遗留模式模式
参考:#3424, #3430
杂项
- [功能] [扩展]
支持将*args
传递给烘焙查询的初始可调用对象,方式与BakedQuery.add_criteria()
和BakedQuery.with_criteria()
方法支持*args
的方式相同。初始 PR 由 Naoki INADA 提供。 - [功能] [扩展]
向MutableBase
添加了一个新的半公共方法MutableBase._get_listen_keys()
。在需要时重写此方法,如果MutableBase
子类需要使事件传播到与可变类型关联的键以外的属性键时,当拦截InstanceEvents.refresh()
或InstanceEvents.refresh_flush()
事件时。目前的示例是使用MutableComposite
的复合体。
参考:#3427 - [错误] [扩展]
由于对#3167的错误修复,sqlalchemy.ext.mutable
扩展中出现了回归,其中属性和验证事件不再在刷新过程中调用。在列级别的 Python 端默认值负责生成 INSERT 或 UPDATE 的新值,或者在“eager defaults”模式下从 RETURNING 子句中获取值时,可变扩展依赖于此行为。当填充新值时,不会触发任何事件,可变扩展无法建立正确的强制转换或历史监听。添加了一个新事件InstanceEvents.refresh_flush()
,可变扩展现在在这种情况下使用。
参考:#3427
ORM
- [ORM] [特性]
添加了新事件InstanceEvents.refresh_flush()
,在刷新过程中调用 INSERT 或 UPDATE 级别的默认值通过 RETURNING 或 Python 端默认值获取时调用。这是为了提供一个钩子,因为由于#3167,属性和验证事件不再在刷新过程中调用。
参考:#3427 - [ORM] [错误]
当Query
返回行时使用的“轻量级命名元组”未正确实现__slots__
,导致仍然有一个__dict__
。这个问题已经解决,但在极不可能的情况下,如果有人给返回的元组赋值,那将不再起作用。
参考:#3420
引擎
- [引擎] [特性]
添加了新的引擎事件ConnectionEvents.engine_disposed()
。在调用Engine.dispose()
方法后调用。 - [引擎] [特性]
调整引擎插件钩子,使得URL.get_dialect()
方法在使用方言插件时仍将返回最终的Dialect
对象,而不需要调用者知道Dialect.get_dialect_cls()
方法。
参考:#3379 - [引擎] [错误]
修复了已知布尔值在engine_from_config()
中未被正确解析的 bug;这些包括pool_threadlocal
和 psycopg2 参数use_native_unicode
。
参考:#3435 - [引擎] [错误]
增加了对行为不端的 DBAPI 的支持,该 DBAPI 将 pep-249 异常名称链接到完全不同名称的异常类,从而阻止 SQLAlchemy 自己的异常包装适当地包装错误。使用的 SQLAlchemy 方言需要实现一个新的访问器DefaultDialect.dbapi_exception_translation_map
来支持此功能;现在已为 py-postgresql 方言实现了这一功能。
参考:#3421 - [引擎] [错误]
修复了一个 bug,涉及当使用池检出事件处理程序并在处理程序中进行连接尝试并失败时,拥有连接记录直到连接错误本身的堆栈跟踪被释放之前不会被释放的情况。对于仅使用单个连接的测试池的情况,这意味着池将完全被检出,直到该堆栈跟踪被释放。这主要影响非常特定的调试场景,不太可能在任何生产应用程序中引起注意。修复方法是在重新引发捕获的异常之前显式检入记录。
参考:#3419
sql
- [sql] [功能]
为Insert.from_select()
中的 SELECT 中使用的 CTE 添加了官方支持。此行为在 0.9.9 之前意外工作,当时由于与 #3248 的不相关更改而不再工作。请注意,这是在 INSERT 之后、SELECT 之前呈现 WITH 子句;在后续版本中,将针对新功能发布顶层 INSERT、UPDATE、DELETE 中呈现 CTE 的完整功能。
此更改也已回溯至:0.9.10
参考:#3418
postgresql
- [postgresql] [错误] [pypy]
修复了与 pypy psycopg2cffi 方言相关的一些打字和测试问题,特别是当前的 2.7.0 版本不支持 JSONB 类型。对于 psycopg2 功能的版本检测已调整为适用于 psycopg2cffi 的特定子版本。此外,已启用了对 psycopg2cffi 下所有 psycopg2 功能的测试覆盖。
参考:#3439
mssql
- [mssql] [bug]
添加了一个新的方言标志到 MSSQL 方言legacy_schema_aliasing
,当设置为 False 时,将禁用一个非常古老和过时的行为,即编译器尝试将所有模式限定的表名转换为别名,以解决 SQL 服务器在所有情况下无法解析多部分标识符名称的旧问题。该行为阻止更复杂的语句正确工作,包括使用提示的语句,以及嵌入相关 SELECT 语句的 CRUD 语句。与其继续修复该功能以使其与更复杂的语句一起工作,不如将其禁用,因为对于任何现代 SQL 服务器版本,它应该不再需要。该标志在 1.0.x 系列中默认为 True,保持当前行为不变。在 1.1 系列中,它将默认为 False。对于 1.0 系列,如果未显式设置为任何值,则在语句中首次使用模式限定表时会发出警告,建议为所有现代 SQL Server 版本将该标志设置为 False。
参见
Legacy Schema Mode
参考:#3424, #3430
杂项
- [feature] [ext]
添加了对*args
的支持,以便像BakedQuery.add_criteria()
和BakedQuery.with_criteria()
方法一样,将*args
传递给烘焙查询的初始可调用函数。初始 PR 由 Naoki INADA 提供。 - [feature] [ext]
添加了一个新的半公开方法到MutableBase
MutableBase._get_listen_keys()
。在拦截InstanceEvents.refresh()
或InstanceEvents.refresh_flush()
事件时,需要重写此方法,以便在MutableBase
子类需要事件传播到与可变类型关联的键之外的属性键时。目前的示例是使用MutableComposite
的复合类型。
参考:#3427 - [bug] [ext]
修复了sqlalchemy.ext.mutable
扩展中的回归,这是由于对#3167的错误修复导致的,其中属性和验证事件不再在刷新过程中调用。可变扩展依赖于这种行为,即在列级 Python 端默认值负责生成 INSERT 或 UPDATE 的新值时,或者当从“eager defaults”模式的 RETURNING 子句中获取值时。当填充新值时,不会触发任何事件,可变扩展无法建立正确的强制转换或历史监听。添加了一个新事件InstanceEvents.refresh_flush()
,可变扩展现在在这种情况下使用。
参考:#3427
1.0.4
发布日期:2015 年 5 月 7 日
orm
- [orm] [错误]
修复了一个意外使用回归,即如果关系的 primaryjoin 涉及与不可哈希类型(如 HSTORE)的比较,由于在语句参数上进行了基于哈希的检查,导致懒加载失败,这是在 1.0 中由于#3061而修改为使用哈希,并在#3368中修改为在比“load on pending”更常见的情况下发生。现在会事先检查值是否具有__hash__
属性。
参考:#3416 - [orm] [错误]
自#3347添加的断言进行了自由化,以防止在使用innerjoin=True
将内连接拼接在一起时出现未知条件;如果一些连接使用了“secondary”表,则需要进一步展开连接以通过断言。
参考:#3347, #3412 - [orm] [错误]
修复/添加了更多表达式的测试,这些表达式被报告为在新添加到Query.column_descriptions
的‘entity’键值后失败,重新设计了发现“from”子句的逻辑,以适应来自别名类的列,以及在这些情况下报告“aliased”标志的正确值。
参考:#3320, #3409
模式
- [模式] [错误]
修复了在#3341中引入的增强约束附加逻辑中的错误,这种不寻常的情况是,约束同时引用Column
对象和字符串列名称的混合,自动附加到列时逻辑将被跳过;对于在这种情况下自动附加约束,必须事先将所有列组装到目标表上。还添加了一个关于原始特性以及这个更改的迁移文档的新部分。
另见
当其引用的列附加到表时,约束引用未附加列可以自动附加到表中
参考资料:#3411
测试
- [tests] [bug] [pypy]
修复了一个导入问题,导致“pypy setup.py test”无法正常工作。
此更改也回溯到:0.9.10
参考资料:#3406
其他
- [bug] [ext]
修复了使用扩展属性仪表化系统时的错误,当调用class_mapper()
时,如果输入无效且无法弱引用,例如整数,则不会引发正确的异常。
此更改也回溯到:0.9.10
参考资料:#3408
orm
- [orm] [bug]
修复了一个意外的回归问题,在这种奇怪的情况下,关系的主要连接涉及与非可散列类型(如 HSTORE)的比较,懒惰加载将失败,因为语句参数上的哈希定向检查在 1.0 中修改为使用哈希化,并在#3368中进行修改以发生在比“加载挂起”更常见的情况下。现在会先检查值是否具有__hash__
属性。
参考资料:#3416 - [orm] [bug]
放宽了一个断言,作为#3347的一部分添加的,以保护在连接到innerjoin=True
的连接的连接中拼接内连接时的未知条件;如果一些连接使用“次要”表,则需要进一步展开连接以通过。
参考资料:#3347, #3412 - [orm] [bug]
修复/添加了更多被报告为在新添加到Query.column_descriptions
的‘entity’键值后失败的表达式的测试,重新调整了发现“from”子句的逻辑,以适应来自别名类的列,以及在这些情况下报告“aliased”标志的正确值。
参考:#3320, #3409
模式
- [schema] [bug]
修复了在#3341中引入的增强约束附加逻辑中的错误,其中在一个约束引用同时引用Column
对象和字符串列名的罕见情况下,自动附加到列时的逻辑将被跳过;在这种情况下,要使约束自动附加,所有列必须事先组装到目标表上。在迁移文档中添加了一个关于原始功能以及此更改的新部分。
参见
引用未附加的列的约束可以在其引用的列附加时自动附加到表格
参考:#3411
测试
- [tests] [bug] [pypy]
修复了一个导入问题,导致“pypy setup.py test”无法正常工作。
此更改也回溯到:0.9.10
参考:#3406
杂项
- [bug] [ext]
修复了使用扩展属性检测系统时的错误,当使用class_mapper()
调用无效输入时,也不是弱引用时,不会引发正确的异常,例如整数。
此更改也回溯到:0.9.10
参考:#3408
1.0.3
发布日期:2015 年 4 月 30 日
orm
- [orm] [bug] [pypy]
从 0.9.10 发布之前修复了由于#3349引起的回归,其中在Query.update()
或Query.delete()
上检查查询状态时,将空元组与自身使用is
进行比较,这在 PyPy 上失败,导致在这种情况下产生True
;这将在 0.9 中错误地发出警告,并在 1.0 中引发异常。
参考:#3405 - [orm] [bug]
修复了在发布之前从 0.9.10 开始的回归,新添加的将entity
添加到Query.column_descriptions
访问器会失败,如果目标实体是从诸如Table
或CTE
对象之类的核心可选择对象生成的。
参考:#3320,#3403 - [orm] [bug]
在刷新过程中修复了一个回归,当属性设置为更新的 SQL 表达式,并且与属性的先前值进行比较的 SQL 表达式会产生==
或!=
之外的 SQL 比较时,异常 “此子句的布尔值未定义” 会引发。修复确保工作单元不会以这种方式解释 SQL 表达式。
参考:#3402 - [orm] [bug]
由于 #2992,修复了由于在联合预加载与Query.order_by()
子句中放置文本元素而导致的意外使用回归,这样会将这些元素添加到内部查询的列子句中,以一种被假定为表绑定列名的方式,这在联合预加载需要将查询包装在子查询中以适应限制/偏移量的情况下会发生。
最初,这里的行为是有意的,即像query(User).order_by('name').limit(1)
这样的查询会按user.name
排序,即使查询被联合预加载修改为在子查询中,因为'name'
会被解释为一个符号,要在 FROM 子句中找到,这种情况下为User.name
,然后将其复制到列子句中以确保其存在以供 ORDER BY 使用。但是,该功能未能预见到order_by("name")
指的是本地列子句中已经存在的特定标签名称,而不是绑定到 FROM 子句中的名称的情况。
此外,该功能还对已弃用的情况(如order_by("name desc")
)失败,尽管它会发出警告,建议在此处使用text()
(请注意,该问题不会影响显式使用text()
的情况),但仍会生成与以前不同的查询,其中“name desc”表达式不当地复制到列子句中。 解决方案是,该功能的“连接式急加载”方面将在增强内部列子句时跳过这些所谓的“标签引用”表达式,就好像它们已经是text()
构造一样。
参考:#3392 - [orm] [bug]
修复了关于MapperEvents.instrument_class()
事件的回归,其中其调用被移动到类管理器对类进行仪器化之后,这与事件文档明确说明的相反。 切换的理由是由于 Declarative 在将类映射为新的@declared_attr
功能描述的目的之前设置了完整的“仪器管理器”,但也针对经典使用Mapper
的一致性进行了更改。 然而,SQLSoup 依赖于在任何经典映射下的仪器化之前发生的仪器化事件。 在经典和声明性映射的情况下,该行为被恢复,后者通过简单的备忘录实现,而不使用类管理器。
参考:#3388 - [orm] [bug]
在新的QueryEvents.before_compile()
事件中修复了一个问题,即在事件中对要加载的实体集合进行更改会反映在 SQL 中,但在加载过程中不会反映。
参考:#3387
engine
- [engine] [feature]
添加了支持引擎/池插件具有高级功能的新功能。在检出的连接包装器级别以及_ConnectionRecord
的连接池中添加了一个新的“软失效”功能。这类似于现代池失效,因为连接不会被主动关闭,但仅在下次检出时被重用;这本质上是该功能的每个连接版本。添加了一个新的事件PoolEvents.soft_invalidate()
来补充它。
还添加了新的标志ExceptionContext.invalidate_pool_on_disconnect
。允许ConnectionEvents.handle_error()
中的错误处理程序维护“断开”条件,但在事件中以特定方式调用单个连接的无效。
参考资料:#3379 - [engine] [feature]
添加了新事件do_connect
,允许拦截/替换调用Dialect.connect()
挂钩以创建 DBAPI 连接时。还添加了方言插件钩子Dialect.get_dialect_cls()
和Dialect.engine_created()
,它允许外部插件使用入口点向现有方言添加事件。
参考:#3355
sql
- [sql] [feature]
添加了一个占位符方法TypeEngine.compare_against_backend()
,从 0.7.6 版本开始被 Alembic 迁移所使用。用户定义的类型可以实现此方法,以帮助比较数据库中反射的类型与另一个类型之间的比较。 - [sql] [bug]
修复了 SQL 中长标签截断可能产生与未截断的另一个标签重叠的错误;这是因为截断的长度阈值大于截断后保留的标签部分。现在,这两个值已经被设置为相同;标签长度 - 6。这里的效果是较短的列标签将在以前不会被截断的地方“截断”。
参考:#3396 - [sql] [bug]
由于#3282导致的回归修复,将tables
集合作为关键字参数传递给DDLEvents.before_create()
、DDLEvents.after_create()
、DDLEvents.before_drop()
和DDLEvents.after_drop()
事件时,不再是表的列表,而是包含第二个条目的元组列表,其中包含要添加或删除的外键。由于tables
集合,虽然文档中说明不一定稳定,但已经被依赖,这种更改被认为是一个回归。此外,在某些情况下,“drop”操作会失败,因为此集合能是一个迭代器,如果过早迭代会导致操作失败。现在,在所有情况下,该集合都是表对象的列表,并且现在已添加了对该集合格式的测试覆盖。
参考:#3391
杂项
- [bug] [ext]
修复了在关联代理中的一个错误,即在关系->标量非对象属性比较上执行 any()/has()时会失败,例如filter(Parent.some_collection_to_attribute.any(Child.attr == 'foo'))
参考:#3397
orm
- [orm] [bug] [pypy]
由于#3349,在发布之前从 0.9.10 版本开始的回归中,Query.update()
或Query.delete()
上的查询状态检查将空元组与自身使用is
进行比较,这在 PyPy 上会失败,导致在这种情况下产生True
;这将在 0.9 中错误地发出警告,并在 1.0 中引发异常。
参考:#3405 - [orm] [bug]
修复了在发布之前从 0.9.10 版本开始的回归,其中将entity
添加到Query.column_descriptions
访问器时,如果目标实体是从核心可选择对象(如Table
或CTE
对象)生成的,将会失败。
参考:#3320, #3403 - [orm] [bug]
修复了在刷新过程中的回归,当属性设置为 UPDATE 的 SQL 表达式时,与属性的先前值进行比较的 SQL 表达式会产生一个不是==
或!=
的 SQL 比较时,将引发异常“此子句的布尔值未定义”。修复确保工作单元不会以这种方式解释 SQL 表达式。
引用:#3402 - [orm] [bug]
修复了由于#2992导致的意外使用回归,其中将文本元素放置到Query.order_by()
子句中,与连接的急加载一起使用时,这些元素将被添加到内部查询的列子句中,以一种被假定为表绑定列名的方式,即在连接的急加载需要将查询包装在子查询中以适应限制/偏移量的情况下。
最初,这里的行为是有意的,例如query(User).order_by('name').limit(1)
这样的查询将按照user.name
排序,即使查询被连接的急加载修改为在子查询中,因为'name'
将被解释为一个符号,应该位于 FROM 子句中,在这种情况下是User.name
,然后将其复制到列子句中以确保它存在于 ORDER BY 中。然而,该功能未能预料到order_by("name")
指的是本地列子句中已经存在的特定标签名称,而不是绑定到 FROM 子句中的名称的情况。
此外,该功能还对已弃用的情况失败,例如order_by("name desc")
,虽然它会发出警告,应该在这里使用text()
(请注意,该问题不影响显式使用text()
的情况),但仍会产生与以前不同的查询,其中“name desc”表达式被不适当地复制到列子句中。解决方案是,该功能的“连接的急加载”方面将跳过这些所谓的“标签引用”表达式,当增强内部列子句时,就像它们已经是text()
构造一样。
引用:#3392 - [orm] [bug]
修复了关于MapperEvents.instrument_class()
事件的回归,其中其调用被移动到类管理器对类进行仪器化之后,这与事件文档明确说明的相反。切换的理由是由于声明性在将类映射为新的@declared_attr
功能描述的目的之前设置了完整的“仪器管理器”,但也针对经典使用Mapper
的一致性进行了更改。然而,SQLSoup 依赖于在任何经典映射下的仪器化之前发生的仪器化事件。在经典和声明性映射的情况下,行为被恢复,后者通过使用简单的记忆化而不使用类管理器来实现。
参考:#3388 - [ORM] [错误]
修复了新QueryEvents.before_compile()
事件中对在事件中加载的实体集合进行更改的问题,这些更改会在 SQL 中呈现,但在加载过程中不会反映出来。
参考:#3387
引擎
- [引擎] [特性]
添加了支持引擎/池插件具有高级功能的新功能。在已检出连接包装器以及_ConnectionRecord
级别的连接池中添加了新的“软无效化”功能。这类似于现代池无效化,即连接不会被主动关闭,而只会在下次检出时被回收;这本质上是该功能的每个连接版本。添加了一个新事件PoolEvents.soft_invalidate()
来补充它。
还添加了新标志ExceptionContext.invalidate_pool_on_disconnect
。允许ConnectionEvents.handle_error()
中的错误处理程序维护“断开”条件,但在事件中以特定方式处理对各个连接的无效化调用。
参考:#3379 - [引擎] [特性]
添加了新的事件do_connect
,允许拦截/替换Dialect.connect()
被调用以创建 DBAPI 连接的钩子。还添加了方言插件钩子Dialect.get_dialect_cls()
和Dialect.engine_created()
,允许外部插件使用入口点向现有方言添加事件。
参考:#3355
sql
- [sql] [feature]
添加了一个占位方法TypeEngine.compare_against_backend()
,自 0.7.6 版开始由 Alembic 迁移使用。用户定义的类型可以实现此方法,以协助比较类型与从数据库反射的类型之间的差异。 - [sql] [bug]
修复了 SQL 中长标签截断可能产生重叠另一个未截断标签的错误。这是因为截断的长度阈值大于截断后剩余标签的部分。现在这两个值已经变成相同的;label_length - 6。这里的效果是,较短的列标签将在以前不会被截断的地方“截断”。
参考:#3396 - [sql] [bug]
由于 #3282 导致的回归错误已修复,其中将tables
集合作为关键字参数传递给DDLEvents.before_create()
、DDLEvents.after_create()
、DDLEvents.before_drop()
和DDLEvents.after_drop()
事件时,不再是表的列表,而是包含第二个条目的元组列表,其中包含要添加或删除的外键。由于tables
集合,虽然文档中声明不一定稳定,但已被依赖,这种变化被认为是一个回归。此外,对于“drop”,在某些情况下,此集合将是一个迭代器,如果过早迭代将导致操作失败。现在,在所有情况下,集合都是表对象的列表,并且现在已添加了此集合格式的测试覆盖。
参考:#3391
杂项
- [bug] [ext]
修复了关于关联代理中的 bug,其中对关系->标量非对象属性比较的 any()/has()会失败,例如filter(Parent.some_collection_to_attribute.any(Child.attr == 'foo'))
参考:#3397
1.0.2
发布日期:2015 年 4 月 24 日
orm declarative
- [orm] [declarative] [bug]
修复了关于声明性__declare_first__
和__declare_last__
访问器的意外使用回归,其中这些访问器将不再在声明性基类的超类上调用。
参考:#3383
sql
- [sql] [bug]
修复了一个回归,该回归在 1.0.0b4 中被错误地修复(因此成为两个回归);报告称 SELECT 语句将对标签名称进行 GROUP BY 并失败,被误解为某些后端(如 SQL Server)根本不应该在简单标签名称上发出 ORDER BY 或 GROUP BY;事实上,我们忘记了 0.9 版本已经对所有后端的简单标签名称进行 ORDER BY,如 Label constructs can now render as their name alone in an ORDER BY 中所述,即使 1.0 包括对此逻辑的重写作为#2992的一部分。关于对简单标签进行 GROUP BY,即使是 PostgreSQL 也有可能出现错误,即使应该明显要对其进行分组,因此很明显不应该自动以这种方式呈现 GROUP BY。
在 1.0.2 版本中,SQL Server、Firebird 等再次在传递Label
构造时对简单标签名称发出 ORDER BY,该构造也存在于列子句中。此外,当传递Label
构造时,任何后端都不会仅对简单标签名称发出 GROUP BY。
参考:#3338, #3385
orm declarative
- [orm] [declarative] [bug]
修复了关于声明性__declare_first__
和__declare_last__
访问器的意外使用回归,其中这些访问器将不再在声明性基类的超类上调用。
参考:#3383
sql
- [sql] [bug]
修复了一个在 1.0.0b4 中错误修复的回归(因此成为两个回归);报告称 SELECT 语句将按标签名称进行 GROUP BY 并失败被误解为某些后端(如 SQL Server)根本不应该在简单标签名称上发出 ORDER BY 或 GROUP BY;事实上,我们忘记了 0.9 版本已经在所有后端上为简单标签名称发出 ORDER BY,如标签构造现在可以仅按其名称在 ORDER BY 中呈现中所述,尽管 1.0 版本包括对此逻辑的重写作为#2992的一部分。至于针对简单标签发出 GROUP BY,即使 PostgreSQL 也有可能会引发错误,尽管应该明显可以分组的标签,因此很明显不应该自动以这种方式呈现 GROUP BY。
在 1.0.2 中,SQL Server、Firebird 和其他后端将再次在传递到Label
构造的简单标签名称时发出 ORDER BY。此外,当传递到Label
构造时,任何后端都不会仅针对简单标签名称发出 GROUP BY。
参考:#3338,#3385
1.0.1
发布日期:2015 年 4 月 23 日
orm
- [orm] [bug]
修复了一个问题,即形式为query(B).filter(B.a != A(id=7))
的查询将在给定瞬态对象时呈现NEVER_SET
符号。对于持久对象,它将始终使用持久化的数据库值而不是当前设置的值。假设自动刷新已打开,对于持久值,这通常对于持久值不会明显,因为任何待处理的更改都将首先刷新。但是,这与非否定比较query(B).filter(B.a == A(id=7))
使用当前值的逻辑不一致,并且还允许与瞬态对象进行比较。比较现在使用当前值而不是数据库持久化的值。
与此版本中由#3061引起的其他NEVER_SET
问题不同,这个特定问题至少从 0.8 版本开始存在,可能更早,但是作为修复相关的NEVER_SET
问题的结果被发现。
另请参见
“否定包含或等于”关系比较将使用属性的当前值,而不是数据库的值。
参考:#3374 - [orm] [bug]
修复了由#3061引起的意外使用回归,其中 NEVER_SET 符号可能会泄漏到基于关系的查询中,包括filter()
和with_parent()
查询。在所有情况下都返回None
符号,但是许多这些查询从未得到正确支持,并且在没有使用 IS 运算符的情况下产生对 NULL 的比较。出于这个原因,还向那些当前不提供IS NULL
的关系查询子集添加了警告。
参见
比较对象与 None 值时发出的警告到关系
参考:#3371 - [ORM] [错误]
修复了由#3061引起的回归,其中 NEVER_SET 符号可能会泄漏到延迟加载查询中,在挂起对象的刷新后发生。这通常会发生在不使用简单“get”策略的多对一关系中。好消息是,该修复改善了与 0.9 相比的效率,因为我们现在可以在检测到参数中存在 NEVER_SET 符号时完全跳过 SELECT 语句;在#3061之前,我们无法确定这里的 None 是否已设置。
参考:#3368
引擎
- [引擎] [错误]
将字符串值"none"
添加到Pool.reset_on_return
参数接受的字符串值之一,作为None
的同义词,以便所有设置都可以使用字符串值,从而允许像engine_from_config()
这样的工具可以无问题地使用。
这个改变也被回溯到了:0.9.10
参考:#3375
sql
- [SQL] [错误]
修复了直接 SELECT EXISTS 查询无法将正确的布尔结果类型分配给结果映射的问题,而是将查询中的列类型泄漏到结果映射中。这个问题在 0.9 版本和更早版本中也存在,但在那些版本中的影响较小。在 1.0 中,由于#918,这成为了一个回归,因为我们现在依赖于结果映射非常准确,否则我们可能会将结果类型处理器分配给错误的列。在所有版本中,这个问题还会导致简单的 EXISTS 不应用布尔类型处理程序,导致在没有本地布尔值的后端中使用简单的 1/0 值而不是 True/False。修复包括 EXISTS 列参数将像其他列表达式一样匿名标记;类似的修复也针对纯布尔表达式如not_(True())
实现。
参考:#3372
sqlite
- [sqlite] [错误]
修复了由于#3282导致的回归,由于我们在创建/删除模式时尝试假设 ALTER 可用,因此在 SQLite 的情况下,我们简单地说根本不用担心外键,因为 ALTER 不可用,当创建和删除表时,这意味着在 SQLite 的情况下基本上跳过了表的排序,对于绝大多数 SQLite 用例,这不是问题。
然而,对于在 SQLite 上执行包含数据的表的 DROP 操作并且打开了引用完整性的用户,然后会遇到错误,因为在 DROP 时依赖排序确实很重要,当这些表包含数据时(SQLite 仍然可以让您创建对不存在表的外键并删除引用具有启用约束的现有表,只要没有引用数据)。
为了在仍允许 SQLite DROP 操作保持排序的同时保持#3282的新功能,我们现在考虑完整的 FK 进行排序,如果遇到无法解决的循环,那么我们才放弃尝试对表进行排序;我们发出警告并使用未排序列表。如果环境需要有序的 DROP 操作并且存在外键循环,那么警告指出他们需要将use_alter
标志恢复到他们的ForeignKey
和ForeignKeyConstraint
对象中,以便仅跳过这些对象的依赖排序。
另请参阅
ForeignKeyConstraint 上的 use_alter 标志(通常)不再需要 - 包含有关 SQLite 的更新说明。
参考:#3378
杂项
- [错误] [firebird]
修复了由于#3034导致的回归,Firebird 方言未正确解释 limit/offset 子句。感谢 effem-git 的拉取请求。
参考:#3380 - [错误] [firebird]
修复了在使用 Firebird 时使用 limit/offset 时“literal_binds”模式的支持,因此当选择此模式时,值再次以内联方式呈现。相关于#3034。
参考:#3381
orm
- [orm] [错误]
修复了一种形式的查询query(B).filter(B.a != A(id=7))
在给定临时对象时会生成NEVER_SET
符号的问题。对于持久化对象,它总是使用持久化的数据库值而不是当前设置的值。假设自动刷新已打开,这通常对于持久值不会明显,因为任何待处理的更改都会被首先刷新。但是,这与非否定比较使用的逻辑不一致,query(B).filter(B.a == A(id=7))
,它确实使用当前值,并且还允许与临时对象进行比较。比较现在使用当前值而不是数据库持久值。
与此版本中由#3061引起的回归修复的其他NEVER_SET
问题不同,这个特定问题至少存在于 0.8 版本,并且可能更早,但是它是在修复相关的NEVER_SET
问题时被发现的。
另请参阅
“否定包含或等于”关系比较将使用属性的当前值,而不是数据库的值
引用:#3374 - [orm] [bug]
修复了由#3061引起的意外使用回归,其中 NEVER_SET 符号可能会渗漏到基于关系的查询中,包括filter()
和with_parent()
查询。在所有情况下都返回None
符号,但是其中许多查询在任何情况下都从未正确支持,并且产生对 NULL 的比较而不使用 IS 运算符。因此,还在那些当前不提供IS NULL
的关系查询子集中添加了警告。
另请参阅
当将对象与空值比较时发出警告
引用:#3371 - [orm] [bug]
修复了由#3061引起的回归,其中 NEVER_SET 符号可能会渗漏到延迟加载查询中,在挂起对象刷新后发生。这通常会发生在不使用简单的“get”策略的一对多关系中。好消息是,该修复提高了效率,因为我们现在可以在检测到参数中存在 NEVER_SET 符号时完全跳过 SELECT 语句;在#3061之前,我们无法判断这里的 None 是否已设置。
引用:#3368
engine
- [engine] [bug]
将字符串值"none"
添加到Pool.reset_on_return
参数接受的值中,作为None
的同义词,这样字符串值就可以用于所有设置,允许像engine_from_config()
这样的实用程序无问题地可用。
此更改也被回移到:0.9.10
参考:#3375
sql
- [sql] [bug]
修复了直接的 SELECT EXISTS 查询无法将 Boolean 的正确结果类型分配给结果映射的问题,而是会将查询内部的列类型泄漏到结果映射中。这个问题在 0.9 及更早版本中也存在,但在那些版本中影响较小。在 1.0 中,由于#918,这成为了一个回归,因为我们现在依赖于结果映射非常准确,否则我们可能会将结果类型处理器分配给错误的列。在所有版本中,这个问题还有一个影响,即简单的 EXISTS 不会应用 Boolean 类型处理程序,导致没有本地布尔值的后端的简单的 1/0 值而不是 True/False。修复包括 EXISTS 列参数将被匿名标记,就像其他列表达式一样;对纯布尔表达式(如not_(True())
)也实现了类似的修复。
参考:#3372
sqlite
- [sqlite] [bug]
修复了由于#3282导致的一个回归,由于我们尝试假设在创建/删除模式时 ALTER 可用,因此在 SQLite 的情况下,我们简单地说根本不必担心外键,因为在创建和删除表时 ALTER 不可用。这意味着在 SQLite 的情况下基本上跳过了表的排序,在绝大多数 SQLite 使用情况下,这不是一个问题。
但是,对于启用了强制约束的带有数据的表在 SQLite 上执行 DROP 的用户将会遇到错误,因为在 DROP 时依赖排序确实很重要,当这些表具有数据时(SQLite 仍然乐意让您创建对不存在表的外键并删除引用已存在表的具有启用约束的表,只要没有引用数据)。
为了保持 #3282 的新功能,同时仍允许 SQLite 的 DROP 操作保持排序,我们现在考虑完整的外键进行排序,如果遇到无法解决的循环,那么我们放弃尝试对表进行排序;我们会发出警告并使用未排序的列表。如果一个环境既需要有序的 DROP 操作 又 存在外键循环,那么警告指出他们需要将ForeignKey
和ForeignKeyConstraint
对象的use_alter
标志恢复,以便只有这些对象会被排除在依赖排序之外。
另请参阅
ForeignKeyConstraint 上的 use_alter 标志(通常)不再需要 - 包含有关 SQLite 的更新说明。
参考:#3378
杂项
- [bug] [firebird]
修复了由于 #3034 导致的回归,导致 Firebird 方言未正确解释 limit/offset 子句。感谢 effem-git 提交的拉取请求。
参考:#3380 - [bug] [firebird]
修复了在使用 Firebird 时在“literal_binds”模式下使用 limit/offset 时的支持,因此当选择此模式时,值再次以内联方式呈现。与 #3034 相关。
参考:#3381
1.0.0
发布日期:2015 年 4 月 16 日
orm
- [orm] [feature]
添加了新参数Query.update.update_args
,允许传递 kw 参数,如mysql_limit
到底层的Update
构造。感谢 Amir Sadoughi 提交的拉取请求。 - [orm] [bug]
发现了处理多次对相同目标进行Query.join()
时的不一致性;它仅在关系连接的情况下隐式去重,并且由于 #3233,在 1.0 中,对同一张表进行两次连接的行为与 0.9 不同,不再错误地别名。为了帮助记录这一变化,迁移说明中关于 #3233 的措辞已经泛化,并且在多次针对相同目标关系调用Query.join()
时添加了警告。
参考:#3367 - [orm] [bug]
在确定半自引用关系的远程端时,对关系的启发式进行了小改进(例如,两个连接的继承子类相互引用),非简单的连接条件会考虑父实体并可以减少使用remote()
注释的需要;这可以恢复一些在 0.9.4 之前可能在没有注释的情况下工作的情况,参见#2948。
参考:#3364
sql
- [sql] [feature]
用于对Table
对象进行排序的拓扑排序,并通过MetaData.sorted_tables
集合提供,现在将产生确定性的排序;也就是说,给定一组具有特定名称和依赖关系的表,每次都会产生相同的排序。这有助于比较 DDL 脚本和其他用例。表按名称发送到拓扑排序,拓扑排序本身将以有序的方式处理传入的数据。感谢 Sebastian Bank 的拉取请求。
另请参阅
MetaData.sorted_tables 访问器是“确定性”的
参考:#3084 - [sql] [bug]
修复了一个问题,即使用命名约定的MetaData
对象在 pickle 时无法正常工作。属性被跳过,导致不一致性和失败,如果反序列化的MetaData
对象用于基于其他表的附加表。
此更改也回溯到:0.9.10
参考:#3362
postgresql
- [postgresql] [bug]
修复了一个长期存在的 bug,即在 psycopg2 方言中与非 ASCII 值和native_enum=False
一起使用Enum
类型时,无法正确解码返回结果。这源自于 PGENUM
类型曾经是一个独立的类型,没有“非本地”选项。
此更改也回溯到:0.9.10
参考:#3354
mssql
- [mssql] [bug]
修复了一个回归问题,即“最后插入的 id”机制在 MSSQL 上执行 INSERT 时会失败,如果主键值在执行之前的插入参数中存在,以及在从 SELECT 进行的 INSERT 中,目标列被声明为列对象而不是字符串键时,会存储不正确的值。
参考:#3360 - [mssql] [bug]
现在使用 pymssql 中的Binary
构造函数,而不是打补丁。感谢 Ramiro Morales 的拉取请求。
测试
- [测试] [错误]
修复了测试运行时使用的路径;对于 sqla_nose.py 和 py.test,如果未设置 sys.flags.no_user_site,则再次在 sys.path 的开头插入“./lib”前缀;这使其的行为就像 Python 默认情况下将“.”放在当前路径一样。对于 tox,我们现在设置了 PYTHONNOUSERSITE 标志。
参考:#3356
ORM
- [ORM] [功能]
添加了新参数Query.update.update_args
,允许传递诸如mysql_limit
之类的关键字参数到底层的Update
构造。感谢 Amir Sadoughi 的拉取请求。 - [ORM] [错误]
发现处理多次对同一目标进行Query.join()
时存在不一致性;它仅在关系连接的情况下隐式去重,并且由于#3233,在 1.0 中两次连接到同一表的行为与 0.9 不同,不再错误地别名。为了帮助记录这一变化,在迁移说明中关于#3233的措辞已经被概括,并且在多次针对同一目标关系调用Query.join()
时添加了警告。
参考:#3367 - [ORM] [错误]
在确定半自引用关系的远程端时,改进了关系的启发式算法,考虑到父实体并且可以减少使用remote()
注释的需要;这可以恢复一些在 0.9.4 之前可能在没有注释的情况下工作的情况,通过#2948。
参考:#3364
SQL
- [SQL] [功能]
用于对Table
对象进行排序的拓扑排序,并通过MetaData.sorted_tables
集合提供,现在将产生一个确定性排序;也就是说,给定一组具有特定名称和依赖关系的表,每次都会产生相同的顺序。这有助于比较 DDL 脚本和其他用例。表按名称发送到拓扑排序,拓扑排序本身将以有序的方式处理传入的数据。感谢 Sebastian Bank 的拉取请求。
另请参阅
MetaData.sorted_tables accessor is “deterministic”
参考:#3084 - [sql] [bug]
修复了使用命名约定的MetaData
对象无法正确与 pickle 配合使用的问题。属性被跳过,导致如果从未拾取的MetaData
对象派生其他表,则会出现不一致和失败。
此更改也被回溯到:0.9.10
参考:#3362
postgresql
- [postgresql] [bug]
修复了一个长期存在的 bug,即在与 psycopg2 方言一起使用时,Enum
类型与非 ASCII 值和native_enum=False
结合使用时无法正确解码返回结果。这源于 PGENUM
类型曾经是一个独立的类型,没有“非本地”选项。
此更改也被回溯到:0.9.10
参考:#3354
mssql
- [mssql] [bug]
修复了一个回归,即“最后插入的 id”机制在 MSSQL 上在插入时未能存储正确的值,当主键值在执行之前出现在插入参数中时,以及在从 SELECT 插入时,目标列被声明为列对象而不是字符串键的情况下。
参考:#3360 - [mssql] [bug]
现在使用 pymssql 中现有的Binary
构造函数,而不是打补丁。感谢 Ramiro Morales 的拉取请求。
tests
- [tests] [bug]
修复了测试运行时使用的路径;对于 sqla_nose.py 和 py.test,再次在 sys.path 的开头插入“./lib”前缀,但仅当 sys.flags.no_user_site 未设置时;这使其表现得就像 Python 默认将“.”放在当前路径中一样。对于 tox,我们现在设置了 PYTHONNOUSERSITE 标志。
参考:#3356
1.0.0b5
发布日期:2015 年 4 月 3 日
orm
- [orm] [bug]
修复了一个 bug,在多个嵌套的Session.begin_nested()
操作中,状态跟踪在内部保存点中更新的对象的“dirty”标志未能传播,因此,如果回滚封闭保存点,则对象将不会成为过期状态的一部分,因此将恢复为其数据库状态。
此更改也回溯到:0.9.10
参考:#3352 - [orm] [bug]
当使用Query.update()
或Query.delete()
方法时,Query
不支持连接、子选择或特殊的 FROM 子句;如果调用了像Query.join()
或Query.select_from()
这样的方法,而不是在静默中忽略这些字段,将引发错误。在 0.9.10 中,这只会发出警告。
参考:#3349 - [orm] [bug]
在会话的提交阶段中,对一个弱字典进行了 list()调用,如果没有它,可能会在进程中与垃圾回收交互时引发“dictionary changed size during iter”错误。此更改由#3139 引入。 - [orm] [bug]
修复了与“嵌套”内连接贪婪加载相关的 bug,在 0.9 中也存在,但在 1.0 中更像是一个回归,因为#3008默认打开了“嵌套”,这样,一个跨越共同祖先的兄弟路径的连接贪婪加载将正确地将每个“innerjoin”兄弟拼接到连接的适当部分,当一系列内部/外部连接混合在一起时。
参考:#3347
sql
- [sql] [bug]
对于非 Unicode 类型的 Unicode 类型发出的警告已经放宽,以便对不是字符串值的值发出警告,例如整数;以前,1.0 的更新警告系统使用了字符串格式化操作,这将引发内部 TypeError。虽然这些情况理想情况下应该完全引发错误,但一些后端,如 SQLite 和 MySQL 确实接受它们,并且可能被传统代码使用,更不用说如果目标后端关闭了 Unicode 转换,它们将始终通过。
参考:#3346
postgresql
- [postgresql] [bug]
修复了一个 bug,其中更新的 PG 索引反映结果 #3184 会导致 PostgreSQL 版本 8.4 及更早版本的索引操作失败。当使用旧版本的 PostgreSQL 时,现在已禁用了这些增强功能。
参考:#3343
orm
- [orm] [bug]
修复了一个 bug,其中在多个嵌套的Session.begin_nested()
操作内的状态跟踪将无法传播对象的“脏”标志,该对象已在内部保存点中更新,因此,如果回滚了封闭的保存点,则该对象将不会成为已过期状态的一部分,因此将恢复到其数据库状态。
此更改也被回溯到:0.9.10
参考:#3352 - [orm] [bug]
Query
在使用Query.update()
或Query.delete()
方法时不支持连接、子查询或特殊的 FROM 子句;如果已调用Query.join()
或Query.select_from()
等方法,而不是在这些字段上静默地忽略这些字段,则会引发错误。在 0.9.10 中,这只会发出警告。
参考:#3349 - [orm] [bug]
在会话的提交阶段中的弱字典周围添加了一个 list() 调用,如果垃圾收集与进程交互,而没有它,则可能会导致“迭代期间字典大小已更改”错误。该更改由 #3139 引入。 - [orm] [bug]
修复了与“嵌套”内连接急切加载相关的 bug,该 bug 在 0.9 中也存在,但由于 #3008 而在 1.0 中更是一种退化,默认情况下启用“嵌套”,因此,当使用 innerjoin=True 的连接急切加载从共同祖先跨越兄弟路径时,将每个“innerjoin”兄弟正确地拼接到连接的适当部分中,当一系列的内/外连接混合在一起时。
参考:#3347
sql
- [sql] [bug]
对于非 Unicode 类型的 unicode 类型发出的警告已放宽,以警告不是字符串值的值,例如整数;以前,1.0 的更新警告系统使用了字符串格式化操作,这会引发内部 TypeError。虽然这些情况理想情况下应完全引发,但一些后端(如 SQLite 和 MySQL)确实接受它们,并且可能在遗留代码中使用,更不用说如果目标后端关闭了 unicode 转换,它们将始终通过。
参考:#3346
postgresql
- [postgresql] [bug]
修复了一个问题,即更新了 #3184 导致的 PG 索引反射会导致在 PostgreSQL 8.4 及更早版本上索引操作失败的 bug。当使用较旧版本的 PostgreSQL 时,现在已禁用了这些增强功能。
参考:#3343
1.0.0b4
发布日期:2015 年 3 月 29 日
sql
- [sql] [bug]
修复了 #2992 中新的“标签解析”功能中的 bug,其中一个匿名标签,然后再次用名称标记时,无法通过文本标签定位。当在查询中为映射的column_property()
显式地指定一个标签时,自然会发生这种情况。
参考:#3340 - [sql] [bug]
修复了 #2992 中新的“标签解析”功能的 bug,其中在语句的 order_by() 或 group_by() 中放置的字符串标签会更优先于在 FROM 子句内找到的名称,而不是更本地可用的列子句内的名称。
参考:#3335
架构
- [schema] [feature]
对约束的“自动附加”功能(如UniqueConstraint
和CheckConstraint
)进行了进一步增强,使得当约束与非绑定到表的Column
对象相关联时,约束会为列本身设置事件监听器,以便在将列与表相关联时约束自动附加。这在声明式中特别有用,但也是普遍适用的。
另请参阅
当引用未连接的列时,约束可以在其引用的列附加到表时自动附加
参考:#3341
mysql
- [mysql] [bug] [pymysql]
修复了 PyMySQL 在使用“executemany”操作时对 Unicode 支持的问题,当使用 Unicode 参数时,SQLAlchemy 现在将语句和绑定参数都作为 Unicode 对象传递,因为 PyMySQL 通常在内部使用字符串插值来生成最终语句,并且在 executemany 情况下仅对最终语句执行“encode”步骤。
这个更改也被回溯到:0.9.10
参考:#3337
mssql
- [mssql] [bug] [firebird] [oracle] [sybase]
关闭了 MSSQL、Oracle 方言上的“简单排序”标志;这是根据#2992的规定,导致在表达式中有一个在列子句中也被引用的 order by 或 group by 时,即使被引用为表达式对象,也会被复制为标签。对于 MSSQL,现在的行为是默认情况下复制整个表达式,因为 MSSQL 在这些情况下可能会对 GROUP BY 表达式特别挑剔。该标志也被防御性地关闭了 Firebird 和 Sybase 方言。
注意
这个解决方案是错误的,请查看版本 1.0.2 以重新制定这个解决方案。
参考:#3338
sql
- [sql] [bug]
修复了#2992中新“标签解析”功能中的错误,其中一个匿名标签,然后再次使用名称标记,将无法通过文本标签定位。当在查询中为映射的column_property()
给定一个显式标签时,这种情况自然发生。
参考:#3340 - [sql] [bug]
修复了#2992中新“标签解析”功能中的错误,其中在语句的 order_by()或 group_by()中放置的字符串标签会更优先考虑在 FROM 子句中找到的名称,而不是在列子句中更容易找到的名称。
参考:#3335
schema
- [schema] [feature]
对于UniqueConstraint
和CheckConstraint
等约束的“自动附加”功能已进一步增强,以便当约束与非绑定到表的Column
对象相关联时,约束将与列本身设置事件侦听器,以便约束在与表关联的同时自动附加。这特别有助于一些边缘情况下的声明式,但也是一般用途。
另请参阅
当引用的列被附加时,引用未附加的列的约束可以自动附加到表
参考:#3341
mysql
- [mysql] [bug] [pymysql]
修复了 PyMySQL 在使用带有 unicode 参数的“executemany”操作时的 unicode 支持。现在 SQLAlchemy 现在将语句和绑定参数都作为 unicode 对象传递,因为 PyMySQL 通常在内部使用字符串插值来生成最终语句,并且在 executemany 的情况下仅在最终语句上执行“encode”步骤。
这个更改也被回溯到:0.9.10
参考:#3337
mssql
- [mssql] [bug] [firebird] [oracle] [sybase]
在 MSSQL、Oracle 方言上关闭了“简单排序”标志;这个标志根据#2992导致在表达式也在列子句中的 order by 或 group by 被复制为标签,即使被引用为表达式对象。对于 MSSQL,现在的行为是默认情况下复制整个表达式,因为 MSSQL 在 GROUP BY 表达式中可能会挑剔。该标志也被防御性地关闭了 Firebird 和 Sybase 方言。
注意
这个解决方案是不正确的,请查看版本 1.0.2 进行重新处理。
参考:#3338
1.0.0b3
发布日期:2015 年 3 月 20 日
mysql
- [mysql] [bug]
修复了无意中被注释掉的问题 #2771 的提交。
参考:#2771
mysql
- [mysql] [bug]
修复了无意中被注释掉的问题 #2771 的提交。
参考:#2771
1.0.0b2
发布日期:2015 年 3 月 20 日
orm
- [orm] [bug]
修复了从 pullreq github:137 中出现的意外使用回归,其中 Py2K unicode 文字(例如u""
)不会被relationship.cascade
选项接受。感谢 Julien Castets 提交的拉取请求。
参考:#3327
orm declarative
- [orm] [declarative] [change]
放宽了对@declared_attr
对象的一些限制,使得它们可以在声明过程之外被调用;这与 #3150 的增强相关,允许@declared_attr
返回一个基于当前类的缓存值,因为它正在被配置。异常抛出已被移除,行为已更改,使得在声明过程之外,由@declared_attr
装饰的函数每次都像普通的@property
一样被调用,而不使用任何缓存,因为在这个阶段没有可用的缓存。
参考:#3331
engine
- [engine] [bug]
ResultProxy
的“自动关闭”现在是“软”关闭。也就是说,在使用提取方法耗尽所有行后,DBAPI 游标会像以前一样被释放,对象可以安全丢弃,但是提取方法仍然可以被调用,它们将返回一个结果结束对象(对于 fetchone 为 None,对于 fetchmany 和 fetchall 为空列表)。只有显式调用ResultProxy.close()
,这些方法才会引发“结果已关闭”错误。
另请参阅ResultProxy
“自动关闭”现在是“软”关闭
参考:#3329,#3330
mysql
- [mysql] [bug] [py3k]
修复了 Py3K 上未正确使用ord()
函数的BIT
类型。感谢 David Marin 的拉取请求。
此更改也回溯到:0.9.10
参考:#3333 - [mysql] [bug]
修复了完全支持使用'utf8mb4'
MySQL 特定字符集与 MySQL 方言,特别是 MySQL-Python 和 PyMySQL。此外,报告更不寻常字符集如‘koi8u’或‘eucjpms’的 MySQL 数据库也将正常工作。感谢 Thomas Grainger 的拉取请求。
参考:#2771
orm
- [orm] [bug]
修复了从 pullreq github:137 中的意外使用回归,其中 Py2K unicode 文字(例如u""
)将不被relationship.cascade
选项接受。感谢 Julien Castets 的拉取请求。
参考:#3327
orm declarative
- [orm] [declarative] [change]
放宽了对@declared_attr
对象添加的一些限制,使其可以在声明过程之外被调用;这与增强功能#3150 有关,该功能允许@declared_attr
返回一个根据当前类缓存的值,因为它正在配置。已删除异常抛出,并更改了行为,使得在声明过程之外,由@declared_attr
装饰的函数每次都像常规的@property
一样被调用,而不使用任何缓存,因为在这个阶段没有可用的缓存。
参考:#3331
引擎
- [engine] [bug]
ResultProxy
的“自动关闭”现在是“软”关闭。也就是说,在使用提取方法耗尽所有行后,DBAPI 游标会像以前一样被释放,对象可以安全丢弃,但是提取方法仍然可以被调用,它们将返回一个结果结束对象(对于 fetchone 为 None,对于 fetchmany 和 fetchall 为空列表)。只有显式调用ResultProxy.close()
,这些方法才会引发“结果已关闭”错误。
另请参阅
ResultProxy “自动关闭”现在是“软”关闭
参考:#3329, #3330
mysql
- [mysql] [错误] [py3k]
修复了在 Py3K 上未正确使用ord()
函数的BIT
类型。感谢 David Marin 提交的拉取请求。
此更改也被回溯到:0.9.10
参考:#3333 - [mysql] [错误]
修复了完全支持使用'utf8mb4'
这种 MySQL 特定字符集的 MySQL 方言,特别是 MySQL-Python 和 PyMySQL。此外,报告更不寻常字符集的 MySQL 数据库,如 ‘koi8u’ 或 ‘eucjpms’ 也将正常工作。感谢 Thomas Grainger 提交的拉取请求。
参考:#2771
SqlAlchemy 2.0 中文文档(六十三)(5)https://developer.aliyun.com/article/1560866