mysql orm 变更记录_1.4变更日志 — SQLAlchemy 1.4 Documentation

[sql] [feature] ¶

将“from linting”作为内置功能添加到SQL编译器中。这允许编译器维护特定SELECT语句中所有FROM子句的图形,这些语句由WHERE或in JOIN子句中的条件链接,这些子句将这些FROM子句链接在一起。如果两个子句之间没有生成警告的任何一个笛卡尔路径,则它们之间都可能发出警告。由于核心表达式语言和ORM都建立在一个“隐式FROMs”模型上,如果查询的任何部分引用了它,则会自动添加一个特定的FROM子句,因此很容易在无意中发生这种情况,希望新特性能够帮助解决这个问题。

References: #4737

[sql] [feature] [mssql] [oracle] ¶

添加了新的“编译后参数”功能。此功能允许 bindparam() 构造使其值在传递给DBAPI驱动程序之前呈现为SQL字符串,但在编译步骤之后,使用编译器的“literal render”功能。这个特性的直接理由是支持那些不能像数据库驱动程序处理的绑定参数那样工作或执行得不好的限制/偏移方案,同时仍然允许SQLAlchemy SQL构造以其编译的形式进行缓存。新功能的直接目标是SQL Server(和Sybase)使用的不支持绑定参数的“TOP N”子句,以及Oracle方言使用的“ROWNUM”和可选的“FIRST_ROWS()”方案,已知前者在没有绑定参数的情况下性能更好,后者不支持绑定参数。该特性建立在最初开发的机制之上,以支持IN表达式的“扩展”参数。作为此功能的一部分,Oracle use_binds_for_limits 功能已无条件打开,此标志现在已弃用。

References: #4808

[sql] [feature] ¶

在支持的后端添加对正则表达式的支持。定义了两种操作:

支持的后端包括SQLite、PostgreSQL、MySQL/MariaDB和Oracle。

References: #1390

[sql] [feature] ¶

这个 select() 构造和相关构造现在允许在columns子句中复制列标签和列本身,从而精确反映列表达式的传入方式。这允许由执行结果返回的元组匹配最初为选择的内容,即ORM Query 这样可以在两个构造之间建立更好的交叉兼容性。此外,它允许列定位敏感结构,如联合(即 _selectable.CompoundSelect )在特定列可能出现在多个位置的情况下更直观地构造。为了支持这一变化, ColumnCollection 已被修改以支持重复列以及允许整数索引访问。

References: #4753

[sql] [feature] ¶

增强了 select() 构造这样,当在子查询中使用select语句时,不同表中重复的列名现在会自动标记为唯一的标签名,而不需要使用组合了tablename和column name的完整“apply_labels()”功能。最重要的是,在c的子键集合中,键和标签是可以消除歧义的 aliased() 针对实体和任意子查询的组合构造,以使其正确工作,尽管源表中的命名列相同,但无需发出“应用标签”警告。

References: #5221

[sql] [feature] ¶

“expanding-IN”特性在查询执行时根据与语句执行相关的特定参数生成IN表达式,现在用于针对文本值列表生成的all-IN表达式。这使得IN表达式可以独立于传递的值列表而完全可缓存,还包括对空列表的支持。对于IN表达式包含非文本SQL表达式的任何场景,将保留IN中每个位置的旧预呈现行为。这一更改还完善了对元组扩展的支持,以前类型特定的绑定处理器无法生效。

References: #4645

[sql] [feature] ¶

以及作为 #4369 ,添加了一个新功能,旨在减少创建语句的Python开销,允许在指示参数传递给语句对象(如select()、Query()、update()等)时使用lambdas,并允许在lambdas中以类似于“baked Query”系统的方式构造完整语句。使用lambdas的基本原理来自于“baked query”方法,该方法使用lambdas将任何数量的Python代码封装到一个只需要在语句首次构造为字符串时调用的可调用代码中。但是,新特性更加复杂,因为作为参数传递的Python文本值是自动提取的,因此不再需要在此类查询中使用bindparam()对象。该特性的使用是可选的,可以根据需要使用小或大的程度,同时仍然允许语句完全可缓存。

References: #5380

[sql] [usecase] ¶

References: #527

[sql] [usecase] ¶

这个 true() 和 false() 运算符现在可以作为 join() 在不支持“原生布尔”表达式(例如Oracle或SQL Server)的后端上,表达式将呈现为“1=1”表示真,“1=0”表示假。这是多年前在 #2804 for和/或表达式。

[sql] [usecase] ¶

改变方法 __str 属于 ColumnCollection 以避免与python字符串列表混淆。

References: #5191

[sql] [usecase] ¶

向添加支持 FETCH {{FIRST | NEXT}} [ count ] {{ROW | ROWS}} {{ONLY | WITH TIES}} 在所支持的后端的选择中,当前为PostgreSQL、Oracle和MSSQL。

References: #5576

[sql] [usecase] ¶

添加了额外的逻辑,使某些通常包装单个数据库列的SQL表达式将在SELECT语句中使用该列的名称作为其“匿名标签”名称,这可能使结果元组中基于键的查找更直观。最主要的例子是CAST表达式,例如。 CAST(table.colname AS INTEGER) ,它将其默认名称导出为“colname”,而不是通常的“anon_1”标签,即, CAST(table.colname AS INTEGER) AS colname . 如果内部表达式没有名称,则使用前面的“匿名标签”逻辑。当使用SELECT语句时 Select.apply_labels() ,例如ORM发出的那些,标记逻辑将生成 _ 如果在同一列中单独命名。这个逻辑现在适用于 cast() 和 type_coerce() 构造以及一些单元素布尔表达式。

References: #4449

[sql] [change] ¶

“子句强制”系统,它是sqlachemy core接收参数并将其解析为 ClauseElement 为了构建SQL表达式对象,结构已从一系列特殊函数重写为完全一致的基于类的系统。此更改是内部的,在将错误类型的参数传递给表达式对象时,除了更具体的错误消息之外,对最终用户不应产生任何影响,但是此更改是涉及角色和行为的一组更大更改的一部分。 select() 物体。

References: #4617

[sql] [change] ¶

增加了一个核心 Values 对象,该对象允许在支持它的数据库(主要是PostgreSQL和SQL Server)的SQL语句的FROM子句中使用VALUES构造。

References: #4868

[sql] [change] ¶

这个 select() construct正朝着一个新的调用形式移动 select(col1, col2, col3, ..) ,删除所有其他关键字参数,因为这些参数都适合使用生成方法。传递给的列或表参数的单个列表 select() 仍然接受,但是如果表达式以简单的位置样式传递,则不再需要。使用此表单时,不允许使用其他关键字参数。

References: #5284

[sql] [change] ¶

作为SQLAlchemy 2.0迁移项目的一部分,对 SelectBase 类层次结构是所有“select”语句构造的根,因为它们不再直接用作FROM子句,也就是说,它们不再是子类。 FromClause .对于最终用户,更改主要意味着 select() 在另一个的FROM子句中构造 select() 首先需要将它包装在子查询中,这在历史上是通过使用 SelectBase.alias() 方法,现在也可以通过使用 SelectBase.subquery() .在任何情况下,这通常都是一个要求,因为在任何情况下,多个数据库都不会在其FROM子句中接受未命名的select子查询。

References: #4617

[sql] [performance] ¶

对Core和ORM内部结构的全面重组和重构现在允许DQL(例如SELECTs)和DML(例如INSERT、UPDATE、DELETE)区域内的所有Core和ORM语句允许它们的SQL编译以及结果获取元数据的构造在大多数情况下被完全缓存。这有效地提供了过去版本中“Baked Query”扩展为ORM提供的透明和通用版本。新特性可以根据它最终为给定方言生成的字符串计算任何给定SQL结构的缓存键,从而允许每次组成等效select()、Query()、insert()、update()或delete()对象的函数在第一次生成语句后缓存该语句。

这个特性是透明的,但是包括一些新的编程范例,可以用来使缓存更加高效。

References: #4639

[sql] [bug] ¶

修正了从ORM绑定列构造约束时出现的问题,主要是 ForeignKey 但是 UniqueConstraint , CheckConstraint 还有其他,ORM级别 InstrumentedAttribute 被完全丢弃,列中的所有ORM级注释都将被删除;这使得约束仍然是完全可pickle的,而不需要拉入ORM级别的实体。这些注释不必出现在模式/元数据级别。

References: #5001

[sql] [bug] ¶

注册函数名基于 GenericFunction 现在在所有情况下都以不区分大小写的方式检索,从1.3中删除了折旧逻辑,该逻辑暂时允许多个 GenericFunction 存在不同情况的对象。A GenericFunction 它将替换同名的另一个对象,无论它是否区分大小写,都会在替换对象之前发出警告。

References: #4569, #4649

[sql] [bug] ¶

创建 and_() 或 or_() 不带参数或为空的构造 *args 现在将发出一个弃用警告,因为生成的SQL是一个no-op(即,它呈现为一个空字符串)。这种行为被认为是不直观的,所以对于空的或者可能是空的 and_() 或 or_() 例如,布尔结构应该包括在默认值中 and_(True, *args) 或 or_(False, *args) . 与许多主要版本的SQLAlchemy一样,如果 *args 部分非空。

References: #5054

[sql] [bug] ¶

改进了 tuple_() 构造使其在columns子句上下文中使用时行为可预测。在大多数后端,SQL元组不支持作为“SELECT”columns子句元素;在那些支持的后端(PostgreSQL,毫不奇怪),Python DBAPI没有“嵌套类型”的概念,因此在获取此类对象的行时仍然存在挑战。使用 tuple_() 在一个 select() 或 Query 现在将提高 CompileError 在 tuple_() 对象被认为是为了获取行而呈现的(即,如果元组在子查询的columns子句中,则不会引发错误)。ORM使用时 Bundle 每列的子元组都应该作为一个显式的消息返回。此外,元组现在将在所有上下文中使用括号呈现。以前,圆括号不会在导致未定义行为的列上下文中呈现。

References: #5127

[sql] [bug] [postgresql] ¶

改进了对在字符串中包含百分号的列名的支持,包括修复了涉及同时嵌入了带有百分号的列名的同名标签的问题,以及重新建立了对psycopg2方言中嵌入百分号的绑定参数名的支持,使用一个类似于cxu Oracle方言的后期转义过程。

References: #5653

[sql] [bug] ¶

作为的子类创建的自定义函数 FunctionElement 现在将根据函数的“名称”生成一个“匿名标签”,就像其他函数一样 Function 对象,例如。 "SELECT myfunc() AS myfunc_1" . 虽然SELECT语句不再需要标签才能使结果代理对象正常工作,但是ORM仍然通过使用对象作为映射键来定位行中的列,当列表达式具有不同的名称时,这一方法更可靠。在任何情况下,行为现在在由生成的函数之间保持一致 func 以及那些作为习俗产生的 FunctionElement 物体。

References: #4887

[sql] [bug] ¶

改写了 ClauseElement.compare() 方法以新的基于访问者的方法,并额外增加测试覆盖范围,确保 ClauseElement 子类在结构上可以相互精确地比较。目前ORM中很少使用结构比较功能,但它也可能构成新缓存功能的基础。

References: #4336

[sql] [bug] ¶

不赞成使用 DISTINCT ON 用PostgreSQL以外的方言。反对MySQL方言中string distinct的旧用法

References: #4002

[sql] [bug] ¶

A的ORDER BY子句 _selectable.CompoundSelect 例如union、except等在应用时不会呈现与给定列关联的表名。 CompoundSelect.order_by() 就A而言 Table -绑定列。大多数数据库都要求ORDER BY子句中的名称只能表示为与第一条SELECT语句中的名称匹配的标签名称。变化与 #4617 在此之前的解决方法是指 .c 的属性 _selectable.CompoundSelect 以获取没有表名的列。由于子查询现在已命名,因此此更改既允许工作区继续工作,也允许表绑定列以及 CompoundSelect.selected_columns 要在中使用的集合 CompoundSelect.order_by() 方法。

References: #4617

[sql] [bug] ¶

这个 Join construct不再将“onclause”视为要从封闭的FROM列表中省略的附加FROM对象的源 Select 对象作为独立于对象的。这适用于包含对JOIN外部的另一个FROM对象的引用的ON子句;虽然从SQL的角度来看,这通常是不正确的,但是省略它也是不正确的,并且行为更改使 Select / Join 表现得更直观一点。

References: #4621

[sql] [deprecated] ¶

这个 Join.alias() 方法已弃用,将在SQLAlchemy 2.0中删除。应改为使用显式select+子查询或内部表的别名。

References: #5010

[sql] [removed] ¶

在1.3中不推荐使用的“threadlocal”执行策略,以及“引擎策略”和 Engine.contextual_connect 方法。“strategy='mock'”关键字参数目前仍被接受,但有一个弃用警告;请使用 create_mock_engine() 而不是这个用例。

参见

“threadlocal”引擎策略已弃用 -来自1.3迁移说明,其中讨论了弃用的基本原理。

References: #4632

[sql] [removed] ¶

移除 sqlalchemy.sql.visitors.iterate_depthfirst 和 sqlalchemy.sql.visitors.traverse_depthfirst 功能。SQLAlchemy的任何部分都没有使用这些函数。这个 iterate() 和 traverse() 函数通常用于这些函数。还删除了剩余函数中未使用的选项,包括“column_collections”、“schema_visitor”。

[sql] [removed] ¶

从中删除了绑定引擎的概念 Compiler 对象,并删除 .execute() 和 .scalar() 方法从 Compiler . 这些基本上都是十多年前被遗忘的方法,没有实际用途,而且不适合 Compiler 对象本身保持对 Engine .

[sql] [removed] ¶

删除不推荐使用的方法 Compiled.compile , ClauseElement.__and__ 和 ClauseElement.__or__ 和属性 Over.func .

删除不推荐使用的 FromClause.count 方法。请使用 count 功能可从 func 命名空间。

References: #4643

[sql] [removed] ¶

删除不推荐使用的参数 text.bindparams 和 text.typemap . 请参考 TextClause.bindparams() 和 TextClause.columns() 方法。

删除不推荐使用的参数 Table.useexisting . 请使用 Table.extend_existing .

References: #4643

[sql] [renamed] ¶

Table 参数 mustexist 已重命名为 Table.must_exist 使用时会发出警告。

[sql] [renamed] ¶

这个 SelectBase.as_scalar() 和 Query.as_scalar() 方法已重命名为 SelectBase.scalar_subquery() 和 Query.scalar_subquery() ,分别。旧名称继续存在于1.4系列中,并带有拒绝警告。此外,隐性胁迫 SelectBase , Alias 当在列上下文中计算时,也不推荐将其他面向选择的对象转换为标量子查询,并发出警告 SelectBase.scalar_subquery() 应显式调用方法。在以后的主要版本中,此警告将变成一个错误,但是当 SelectBase.scalar_subquery() 需要调用。更改的后一部分是为了清晰和减少查询强制系统的隐式决策。这个 Subquery.as_scalar() 方法,以前是 Alias.as_scalar ,也被弃用; .scalar_subquery() 应该直接从 ` _ 表达式.选择`对象或 :class:`_query.Query() 对象。

此更改是要转换的较大更改的一部分 select() 对象不再是“From子句”类层次结构的直接组成部分,它还包括对子句强制系统的大修。

References: #4617

[sql] [renamed] ¶

几个操作符被重命名,以在SQLAlchemy中实现更一致的命名。

操作员变更如下:

isfalse is now is_false

isnot_distinct_from is now is_not_distinct_from

istrue is now is_true

notbetween is now not_between

notcontains is now not_contains

notendswith is now not_endswith

notilike is now not_ilike

notlike is now not_like

notmatch is now not_match

notstartswith is now not_startswith

nullsfirst is now nulls_first

nullslast is now nulls_last

isnot is now is_not

not_in_ is now not_in

因为这些是核心操作员,因此此更改的内部迁移策略是在较长的时间内(如果不是无限期地)支持遗留术语,但是将所有文档、教程和内部用法更新为新术语。新术语用于定义函数,旧术语已被弃用为新术语的别名。

References: #5429, #5435

[sql] [postgresql] ¶

允许在创建时指定数据类型 Sequence 在PostgreSQL中使用参数 Sequence.data_type .

References: #5498

[sql] [reflection] ¶

在所有支持的后端(sqlite、mysql、postgresql)上,外键的“no action”关键字“on update”现在被认为是外键的默认级联,当检测到时,反射字典中不包括该关键字;对于所有prev,这已经是postgresql和mysql的行为。在任何情况下都是ious sqlachemy版本。当检测到“restrict”关键字时,它会被正向存储;PostgreSQL会报告这个关键字,而8.0版的MySQL也会报告这个关键字。在早期的MySQL版本中,数据库不报告它。

References: #4741

[sql] [reflection] ¶

添加了对反射“identity”列的支持,这些列现在作为 Inspector.get_columns() . 完全反射时 Table 对象,标识列将使用 Identity 构造。目前支持的后端是PostgreSQL>=10、Oracle>=12和MSSQL(具有不同的语法和功能子集)。

References: #5324, #5527

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值