其他的持久化技术¶

Additional Persistence Techniques

将 SQL 插入/更新表达式嵌入到刷新中¶

Embedding SQL Insert/Update Expressions into a Flush

中文

此功能允许数据库列的值被设置为 SQL 表达式，而不是字面量值。它对于原子更新、调用存储过程等特别有用。您只需将表达式赋值给属性:

class SomeClass(Base):
    __tablename__ = "some_table"

    # ...

    value = mapped_column(Integer)

someobject = session.get(SomeClass, 5)

# 将 'value' 属性设置为增加 1 的 SQL 表达式
someobject.value = SomeClass.value + 1

# 发出 "UPDATE some_table SET value=value+1"
session.commit()

该技术适用于 INSERT 和 UPDATE 语句。执行 flush/commit 操作后，上述 someobject 上的 value 属性会被过期，因此在下次访问时，新的值会从数据库中加载。

此功能还具有条件支持，可以与主键列一起使用。对于支持 RETURNING 的数据库（包括 Oracle 数据库、SQL Server、MariaDB 10.5、SQLite 3.35），也可以将 SQL 表达式赋值给主键列。这不仅可以评估 SQL 表达式，还允许成功通过 ORM 获取由服务器端触发器修改主键值的情况:

class Foo(Base):
    __tablename__ = "foo"
    pk = mapped_column(Integer, primary_key=True)
    bar = mapped_column(Integer)

e = create_engine("postgresql+psycopg2://scott:tiger@localhost/test", echo=True)
Base.metadata.create_all(e)

session = Session(e)

foo = Foo(pk=sql.select(sql.func.coalesce(sql.func.max(Foo.pk) + 1, 1)))
session.add(foo)
session.commit()

在 PostgreSQL 上，上述 Session 将发出以下 INSERT：

INSERT INTO foo (foopk, bar) VALUES
((SELECT coalesce(max(foo.foopk) + %(max_1)s, %(coalesce_2)s) AS coalesce_1
FROM foo), %(bar)s) RETURNING foo.foopk

英文

This feature allows the value of a database column to be set to a SQL expression instead of a literal value. It’s especially useful for atomic updates, calling stored procedures, etc. All you do is assign an expression to an attribute:

class SomeClass(Base):
    __tablename__ = "some_table"

    # ...

    value = mapped_column(Integer)


someobject = session.get(SomeClass, 5)

# set 'value' attribute to a SQL expression adding one
someobject.value = SomeClass.value + 1

# issues "UPDATE some_table SET value=value+1"
session.commit()

This technique works both for INSERT and UPDATE statements. After the flush/commit operation, the value attribute on someobject above is expired, so that when next accessed the newly generated value will be loaded from the database.

The feature also has conditional support to work in conjunction with primary key columns. For backends that have RETURNING support (including Oracle Database, SQL Server, MariaDB 10.5, SQLite 3.35) a SQL expression may be assigned to a primary key column as well. This allows both the SQL expression to be evaluated, as well as allows any server side triggers that modify the primary key value on INSERT, to be successfully retrieved by the ORM as part of the object’s primary key:

class Foo(Base):
    __tablename__ = "foo"
    pk = mapped_column(Integer, primary_key=True)
    bar = mapped_column(Integer)


e = create_engine("postgresql+psycopg2://scott:tiger@localhost/test", echo=True)
Base.metadata.create_all(e)

session = Session(e)

foo = Foo(pk=sql.select(sql.func.coalesce(sql.func.max(Foo.pk) + 1, 1)))
session.add(foo)
session.commit()

On PostgreSQL, the above Session will emit the following INSERT:

INSERT INTO foo (foopk, bar) VALUES
((SELECT coalesce(max(foo.foopk) + %(max_1)s, %(coalesce_2)s) AS coalesce_1
FROM foo), %(bar)s) RETURNING foo.foopk

将 SQL 表达式与会话结合使用¶

Using SQL Expressions with Sessions

中文

SQL 表达式和字符串可以通过 Session 在其事务上下文中执行。最简单的方法是使用 Session.execute() 方法，它返回一个 CursorResult，与 Engine 或 Connection 返回的结果相同:

Session = sessionmaker(bind=engine)
session = Session()

# 执行字符串语句
result = session.execute(text("select * from table where id=:id"), {"id": 7})

# 执行 SQL 表达式构造
result = session.execute(select(mytable).where(mytable.c.id == 7))

当前 Connection 可通过 Session.connection() 方法访问：

connection = session.connection()

上述示例涉及一个绑定到单个 Engine 或 Connection 的 Session。要使用一个绑定到多个引擎或没有引擎的 execute 和 Session.connection() 方法接受一个绑定参数字典 Session.execute.bind_arguments，该字典可以包含 “mapper”，其值是一个映射类或 Mapper 实例，用于定位所需引擎的上下文:

Session = sessionmaker()
session = Session()

# 执行时需要指定 mapper 或类
result = session.execute(
    text("select * from table where id=:id"),
    {"id": 7},
    bind_arguments={"mapper": MyMappedClass},
)

result = session.execute(
    select(mytable).where(mytable.c.id == 7), bind_arguments={"mapper": MyMappedClass}
)

connection = session.connection(MyMappedClass)

在 1.4 版本发生变更: mapper 和 clause 参数现在作为字典的一部分传递给 Session.execute()，这个字典被作为 Session.execute.bind_arguments 参数传递。以前的参数仍然被接受，但此用法已被弃用。

英文

SQL expressions and strings can be executed via the Session within its transactional context. This is most easily accomplished using the Session.execute() method, which returns a CursorResult in the same manner as an Engine or Connection:

Session = sessionmaker(bind=engine)
session = Session()

# execute a string statement
result = session.execute(text("select * from table where id=:id"), {"id": 7})

# execute a SQL expression construct
result = session.execute(select(mytable).where(mytable.c.id == 7))

The current Connection held by the Session is accessible using the Session.connection() method:

connection = session.connection()

The examples above deal with a Session that’s bound to a single Engine or Connection. To execute statements using a Session which is bound either to multiple engines, or none at all (i.e. relies upon bound metadata), both Session.execute() and Session.connection() accept a dictionary of bind arguments Session.execute.bind_arguments which may include “mapper” which is passed a mapped class or Mapper instance, which is used to locate the proper context for the desired engine:

Session = sessionmaker()
session = Session()

# need to specify mapper or class when executing
result = session.execute(
    text("select * from table where id=:id"),
    {"id": 7},
    bind_arguments={"mapper": MyMappedClass},
)

result = session.execute(
    select(mytable).where(mytable.c.id == 7), bind_arguments={"mapper": MyMappedClass}
)

connection = session.connection(MyMappedClass)

在 1.4 版本发生变更: the mapper and clause arguments to Session.execute() are now passed as part of a dictionary sent as the Session.execute.bind_arguments parameter. The previous arguments are still accepted however this usage is deprecated.

在具有默认值的列上强制为 NULL¶

Forcing NULL on a column with a default

中文

ORM 将任何从未设置的属性视为“默认”情况；该属性将被省略在 INSERT 语句中:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(String(50), nullable=True)

obj = MyObject(id=1)
session.add(obj)
session.commit()  # INSERT 时省略 'data' 列；数据库
# 会将其持久化为 NULL 值

省略列的 INSERT 意味着该列将被设置为 NULL 值，除非该列已设置默认值，在这种情况下，默认值将被持久化。无论是纯 SQL 角度（服务器端默认值），还是 SQLAlchemy 的插入行为（包括客户端和服务器端默认值）都遵循此行为:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(String(50), nullable=True, server_default="default")

obj = MyObject(id=1)
session.add(obj)
session.commit()  # INSERT 时省略 'data' 列；数据库
# 会将其持久化为 'default' 值

然而，在 ORM 中，即使显式地将 Python 值 None 赋值给对象，这也会被视为 与未赋值相同:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(String(50), nullable=True, server_default="default")

obj = MyObject(id=1, data=None)
session.add(obj)
session.commit()  # INSERT 时将 'data' 列显式设置为 None；
# ORM 仍然将其从语句中省略，数据库仍会将其持久化为 'default'

上述操作将把 data 列持久化为服务器默认值 “default”，而不是 SQL NULL，即使传递了 None；这是 ORM 的长期行为，许多应用程序都将其作为假设。

那么，如果我们实际上想要将 NULL 存入该列，即使该列有默认值怎么办？有两种方法。第一种是在每个实例级别，使用 null SQL 构造赋值给属性:

from sqlalchemy import null

obj = MyObject(id=1, data=null())
session.add(obj)
session.commit()  # INSERT 时将 'data' 列显式设置为 null；
# ORM 直接使用此值，绕过所有客户端和服务器端的默认值，
# 数据库将其持久化为 NULL 值

null SQL 构造总是会直接将 SQL NULL 值插入目标 INSERT 语句中。

如果我们希望能够使用 Python 值 None，并且希望它尽管列有默认值时也能持久化为 NULL，我们可以使用 Core 层修饰符 TypeEngine.evaluates_none() 来为 ORM 配置此行为，该修饰符指示 ORM 应将 None 视为与其他任何值相同并传递它，而不是将其视为“缺失”值并省略:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(
        String(50).evaluates_none(),  # 指示 None 始终传递
        nullable=True,
        server_default="default",
    )

obj = MyObject(id=1, data=None)
session.add(obj)
session.commit()  # INSERT 时将 'data' 列显式设置为 None；
# ORM 直接使用此值，绕过所有客户端和服务器端的默认值，
# 数据库将其持久化为 NULL 值

英文

The ORM considers any attribute that was never set on an object as a “default” case; the attribute will be omitted from the INSERT statement:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(String(50), nullable=True)


obj = MyObject(id=1)
session.add(obj)
session.commit()  # INSERT with the 'data' column omitted; the database
# itself will persist this as the NULL value

Omitting a column from the INSERT means that the column will have the NULL value set, unless the column has a default set up, in which case the default value will be persisted. This holds true both from a pure SQL perspective with server-side defaults, as well as the behavior of SQLAlchemy’s insert behavior with both client-side and server-side defaults:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(String(50), nullable=True, server_default="default")


obj = MyObject(id=1)
session.add(obj)
session.commit()  # INSERT with the 'data' column omitted; the database
# itself will persist this as the value 'default'

However, in the ORM, even if one assigns the Python value None explicitly to the object, this is treated the same as though the value were never assigned:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(String(50), nullable=True, server_default="default")


obj = MyObject(id=1, data=None)
session.add(obj)
session.commit()  # INSERT with the 'data' column explicitly set to None;
# the ORM still omits it from the statement and the
# database will still persist this as the value 'default'

The above operation will persist into the data column the server default value of "default" and not SQL NULL, even though None was passed; this is a long-standing behavior of the ORM that many applications hold as an assumption.

So what if we want to actually put NULL into this column, even though the column has a default value? There are two approaches. One is that on a per-instance level, we assign the attribute using the null SQL construct:

from sqlalchemy import null

obj = MyObject(id=1, data=null())
session.add(obj)
session.commit()  # INSERT with the 'data' column explicitly set as null();
# the ORM uses this directly, bypassing all client-
# and server-side defaults, and the database will
# persist this as the NULL value

The null SQL construct always translates into the SQL NULL value being directly present in the target INSERT statement.

If we’d like to be able to use the Python value None and have this also be persisted as NULL despite the presence of column defaults, we can configure this for the ORM using a Core-level modifier TypeEngine.evaluates_none(), which indicates a type where the ORM should treat the value None the same as any other value and pass it through, rather than omitting it as a “missing” value:

class MyObject(Base):
    __tablename__ = "my_table"
    id = mapped_column(Integer, primary_key=True)
    data = mapped_column(
        String(50).evaluates_none(),  # indicate that None should always be passed
        nullable=True,
        server_default="default",
    )


obj = MyObject(id=1, data=None)
session.add(obj)
session.commit()  # INSERT with the 'data' column explicitly set to None;
# the ORM uses this directly, bypassing all client-
# and server-side defaults, and the database will
# persist this as the NULL value

使用 INSERT、UPDATE 和 ON CONFLICT（即 upsert）返回 ORM 对象¶

Using INSERT, UPDATE and ON CONFLICT (i.e. upsert) to return ORM Objects

中文

SQLAlchemy 2.0 提供了增强的功能，可以发出多种类型的 ORM 启用的 INSERT、UPDATE 和 upsert 语句。有关 upsert 的详细信息，请参阅 ORM“upsert”语句。

英文

SQLAlchemy 2.0 includes enhanced capabilities for emitting several varieties of ORM-enabled INSERT, UPDATE, and upsert statements. See the document at 启用 ORM 的 INSERT、UPDATE 和 DELETE 语句 for documentation. For upsert, see ORM“upsert”语句.

使用 PostgreSQL ON CONFLICT 和 RETURNING 返回更新的 ORM对象¶

Using PostgreSQL ON CONFLICT with RETURNING to return upserted ORM objects

中文

本节已移至 ORM“upsert”语句。

英文

This section has moved to ORM“upsert”语句.

分区策略（例如每个会话有多个数据库后端）¶

Partitioning Strategies (e.g. multiple database backends per Session)

简单垂直分区¶

Simple Vertical Partitioning

中文

垂直分区将不同的类、类层次结构或映射的表分配到多个数据库中，通过使用 Session 配置 Session.binds 参数来实现。该参数接收一个字典，其中包含 ORM 映射的类、映射层次结构中的任意类（例如声明性基类或混入类）、 Table 对象和 Mapper 对象作为键，这些键通常会引用 Engine 或较不常见的 Connection 对象作为目标。每当 Session 需要代表特定类型的映射类发出 SQL 时，该字典会被查询以定位适当的数据库连接源:

engine1 = create_engine("postgresql+psycopg2://db1")
engine2 = create_engine("postgresql+psycopg2://db2")

Session = sessionmaker()

# 将 User 操作绑定到 engine 1，将 Account 操作绑定到 engine 2
Session.configure(binds={User: engine1, Account: engine2})

session = Session()

在上面的示例中，对任意类的 SQL 操作将使用与该类绑定的 Engine。这种功能涵盖了读取和写入操作；针对映射到 engine1 的实体的 Query （通过查看请求的项目列表中的第一个实体确定）将使用 engine1 来运行查询。提交操作将针对每个类使用两个引擎，当它提交 User 和 Account 类型的对象时。

在更常见的情况下，通常会使用基类或混入类来区分不同数据库连接的操作。 Session.binds 参数可以接受任何任意的 Python 类作为键，如果该类在特定映射类的 __mro__ （Python 方法解析顺序）中找到，则会使用该类。假设有两个声明性基类表示两个不同的数据库连接:

from sqlalchemy.orm import DeclarativeBase
from sqlalchemy.orm import Session

class BaseA(DeclarativeBase):
    pass

class BaseB(DeclarativeBase):
    pass

class User(BaseA): ...

class Address(BaseA): ...

class GameInfo(BaseB): ...

class GameStats(BaseB): ...

Session = sessionmaker()

# 所有 User/Address 操作将使用 engine 1，所有 Game 操作将使用 engine 2
Session.configure(binds={BaseA: engine1, BaseB: engine2})

在上面的示例中，派生自 BaseA 和 BaseB 的类将根据它们的超类，将其 SQL 操作路由到其中一个引擎。如果某个类同时继承多个“绑定”超类，则会选择目标类层次结构中位于最顶部的超类来决定使用哪个引擎。

参见

Session.binds

英文

Vertical partitioning places different classes, class hierarchies, or mapped tables, across multiple databases, by configuring the Session with the Session.binds argument. This argument receives a dictionary that contains any combination of ORM-mapped classes, arbitrary classes within a mapped hierarchy (such as declarative base classes or mixins), Table objects, and Mapper objects as keys, which then refer typically to Engine or less typically Connection objects as targets. The dictionary is consulted whenever the Session needs to emit SQL on behalf of a particular kind of mapped class in order to locate the appropriate source of database connectivity:

engine1 = create_engine("postgresql+psycopg2://db1")
engine2 = create_engine("postgresql+psycopg2://db2")

Session = sessionmaker()

# bind User operations to engine 1, Account operations to engine 2
Session.configure(binds={User: engine1, Account: engine2})

session = Session()

Above, SQL operations against either class will make usage of the Engine linked to that class. The functionality is comprehensive across both read and write operations; a Query that is against entities mapped to engine1 (determined by looking at the first entity in the list of items requested) will make use of engine1 to run the query. A flush operation will make use of both engines on a per-class basis as it flushes objects of type User and Account.

In the more common case, there are typically base or mixin classes that can be used to distinguish between operations that are destined for different database connections. The Session.binds argument can accommodate any arbitrary Python class as a key, which will be used if it is found to be in the __mro__ (Python method resolution order) for a particular mapped class. Supposing two declarative bases are representing two different database connections:

from sqlalchemy.orm import DeclarativeBase
from sqlalchemy.orm import Session

class BaseA(DeclarativeBase):
    pass

class BaseB(DeclarativeBase):
    pass

class User(BaseA): ...

class Address(BaseA): ...

class GameInfo(BaseB): ...

class GameStats(BaseB): ...

Session = sessionmaker()

# all User/Address operations will be on engine 1, all
# Game operations will be on engine 2
Session.configure(binds={BaseA: engine1, BaseB: engine2})

Above, classes which descend from BaseA and BaseB will have their SQL operations routed to one of two engines based on which superclass they descend from, if any. In the case of a class that descends from more than one “bound” superclass, the superclass that is highest in the target class’ hierarchy will be chosen to represent which engine should be used.

参见

Session.binds

多引擎会话的事务协调¶

Coordination of Transactions for a multiple-engine Session

中文

使用多个绑定引擎时有一个注意事项，即在一个后端的提交操作成功后，另一个后端的提交操作可能会失败。这是一个一致性问题，在关系型数据库中通常通过“二阶段事务”来解决，该事务在提交序列中增加了一个“准备”步骤，允许多个数据库在实际完成事务之前同意提交。

由于 DBAPI 的支持有限，SQLAlchemy 对跨后端的二阶段事务支持有限。通常已知与 PostgreSQL 后端兼容得较好，与 MySQL 后端的兼容性较差。然而，当后端支持时，Session 完全能够利用二阶段事务功能，方法是通过在 sessionmaker 或 Session 中设置 Session.use_twophase 标志。有关示例，请参见启用两阶段提交。

英文

One caveat to using multiple bound engines is in the case where a commit operation may fail on one backend after the commit has succeeded on another. This is an inconsistency problem that in relational databases is solved using a “two phase transaction”, which adds an additional “prepare” step to the commit sequence that allows for multiple databases to agree to commit before actually completing the transaction.

Due to limited support within DBAPIs, SQLAlchemy has limited support for two- phase transactions across backends. Most typically, it is known to work well with the PostgreSQL backend and to a lesser extent with the MySQL backend. However, the Session is fully capable of taking advantage of the two phase transaction feature when the backend supports it, by setting the Session.use_twophase flag within sessionmaker or Session. See 启用两阶段提交 for an example.

自定义垂直分区¶

Custom Vertical Partitioning

中文

通过覆盖 Session.get_bind() 方法，可以构建更全面的基于规则的类级分区。下面我们展示了一个自定义的 Session，它实现了以下规则：

Flush 操作，以及批量的 “update” 和 “delete” 操作，被交付到名为 leader 的引擎。
所有继承自 MyOtherClass 的对象操作，都将在 other 引擎上执行。
所有其他类的读操作，将随机选择 follower1 或 follower2 数据库。

engines = {
    "leader": create_engine("sqlite:///leader.db"),
    "other": create_engine("sqlite:///other.db"),
    "follower1": create_engine("sqlite:///follower1.db"),
    "follower2": create_engine("sqlite:///follower2.db"),
}

from sqlalchemy.sql import Update, Delete
from sqlalchemy.orm import Session, sessionmaker
import random


class RoutingSession(Session):
    def get_bind(self, mapper=None, clause=None):
        if mapper and issubclass(mapper.class_, MyOtherClass):
            return engines["other"]
        elif self._flushing or isinstance(clause, (Update, Delete)):
            # 注：这是为了示例，然而在实践中，读写分离通常会通过在
            # 顶层使用两个不同的 Session 来实现。
            # 请参阅下面的注释
            return engines["leader"]
        else:
            return engines[random.choice(["follower1", "follower2"])]

上述 Session 类通过 class_ 参数传递给 sessionmaker 使用:

Session = sessionmaker(class_=RoutingSession)

这种方法可以与多个 MetaData 对象结合使用，方法之一是使用声明性 __abstract__ 关键字，详细说明见 __abstract__。

备注

上面的示例说明了如何根据 SQL 语句是否需要写入数据来路由到所谓的“leader”或“follower”数据库。然而，这种方法可能不是一个实用的方式，因为它会导致读写操作之间的不协调事务行为。在实践中，最好在开始时将 Session 构建为“读取”或“写入”会话，依据整体操作或事务的性质来决定。这样，写入数据的操作也会在同一事务范围内执行读取查询。参见为 Sessionmaker/引擎范围设置隔离中的示例，该示例设置了一个“只读”操作的 sessionmaker，使用自动提交连接，另一个则用于“写入”操作，其中将包含 DML / COMMIT。

参见

Django风格的数据库路由器在SQLAlchemy中的实现 - 一篇关于 Session.get_bind() 更全面示例的博客文章

英文

More comprehensive rule-based class-level partitioning can be built by overriding the Session.get_bind() method. Below we illustrate a custom Session which delivers the following rules:

Flush operations, as well as bulk “update” and “delete” operations, are delivered to the engine named leader.
Operations on objects that subclass MyOtherClass all occur on the other engine.
Read operations for all other classes occur on a random choice of the follower1 or follower2 database.

engines = {
    "leader": create_engine("sqlite:///leader.db"),
    "other": create_engine("sqlite:///other.db"),
    "follower1": create_engine("sqlite:///follower1.db"),
    "follower2": create_engine("sqlite:///follower2.db"),
}

from sqlalchemy.sql import Update, Delete
from sqlalchemy.orm import Session, sessionmaker
import random


class RoutingSession(Session):
    def get_bind(self, mapper=None, clause=None):
        if mapper and issubclass(mapper.class_, MyOtherClass):
            return engines["other"]
        elif self._flushing or isinstance(clause, (Update, Delete)):
            # NOTE: this is for example, however in practice reader/writer
            # splits are likely more straightforward by using two distinct
            # Sessions at the top of a "reader" or "writer" operation.
            # See note below
            return engines["leader"]
        else:
            return engines[random.choice(["follower1", "follower2"])]

The above Session class is plugged in using the class_ argument to sessionmaker:

Session = sessionmaker(class_=RoutingSession)

This approach can be combined with multiple MetaData objects, using an approach such as that of using the declarative __abstract__ keyword, described at __abstract__.

备注

While the above example illustrates routing of specific SQL statements to a so-called “leader” or “follower” database based on whether or not the statement expects to write data, this is likely not a practical approach, as it leads to uncoordinated transaction behavior between reading and writing within the same operation. In practice, it’s likely best to construct the Session up front as a “reader” or “writer” session, based on the overall operation / transaction that’s proceeding. That way, an operation that will be writing data will also emit its read-queries within the same transaction scope. See the example at 为 Sessionmaker/引擎范围设置隔离 for a recipe that sets up one sessionmaker for “read only” operations using autocommit connections, and another for “write” operations which will include DML / COMMIT.

参见

Django-style Database Routers in SQLAlchemy - blog post on a more comprehensive example of Session.get_bind()

水平分区¶

Horizontal Partitioning

中文

水平分区将单个表（或一组表）的行分配到多个数据库中。 SQLAlchemy 的 Session 支持这个概念，然而要完全利用它，需要使用 Session 和 Query 子类。这些子类的基础版本可在水平分片 ORM 扩展中找到。使用示例可以参考水平分片。

英文

Horizontal partitioning partitions the rows of a single table (or a set of tables) across multiple databases. The SQLAlchemy Session contains support for this concept, however to use it fully requires that Session and Query subclasses are used. A basic version of these subclasses are available in the 水平分片 ORM extension. An example of use is at: 水平分片.

批量操作¶

Bulk Operations

中文

Legacy Feature

SQLAlchemy 2.0 已将 Session 的“批量插入”和 “批量更新”功能集成到 2.0 风格的 Session.execute() 方法中，该方法直接使用 Insert 和 Update 构造。请参见文档启用 ORM 的 INSERT、UPDATE 和 DELETE 语句，其中包括旧会话批量 INSERT 方法，说明了如何从旧方法迁移到新方法。

英文

Legacy Feature

SQLAlchemy 2.0 has integrated the Session “bulk insert” and “bulk update” capabilities into 2.0 style Session.execute() method, making direct use of Insert and Update constructs. See the document at 启用 ORM 的 INSERT、UPDATE 和 DELETE 语句 for documentation, including 旧会话批量 INSERT 方法 which illustrates migration from the older methods to the new methods.

其他的持久化技术¶

将 SQL 插入/更新表达式嵌入到刷新中¶

将 SQL 表达式与会话结合使用¶

在具有默认值的列上强制为 NULL¶

获取服务器生成的默认值¶

情况 1：支持非主键、RETURNING 或等效项¶

情况 2：表包含与 RETURNING 不兼容的触发器生成的值¶

情况 3：不支持或不需要非主键、RETURNING 或等效项¶

情况 4：支持主键、RETURNING 或等效项¶

情况 5：不支持主键、RETURNING 或等效项¶

带有 DateTime 主键的 MySQL¶

带有 TIMESTAMP 主键的 MySQL¶

关于急切获取用于 INSERT 或 UPDATE 的客户端调用 SQL 表达式的说明¶