Support for the Microsoft SQL Server database.
The following dialect/DBAPI options are available. Please refer to individual DBAPI sections for connect information.
SQL Server使用 IDENTITY
构造,它可以放置在表中的任何单个整数列上。SQLAlchemy考虑 IDENTITY
在整数主键列的默认“autoincrement”行为中,如中所述 Column.autoincrement
. 这意味着默认情况下,在 Table
将被视为标识列,并将生成DDL,如下所示:
from sqlalchemy import Table, MetaData, Column, Integer
m = MetaData()
t = Table('t', m,
Column('id', Integer, primary_key=True),
Column('x', Integer))
m.create_all(engine)
上面的示例将生成DDL,如下所示:
CREATE TABLE t (
id INTEGER NOT NULL IDENTITY(1,1),
x INTEGER NULL,
PRIMARY KEY (id)
)
对于此默认生成的 IDENTITY
不需要,请指定 False
对于 Column.autoincrement
标志,在第一个整数主键列上::
m = MetaData()
t = Table('t', m,
Column('id', Integer, primary_key=True, autoincrement=False),
Column('x', Integer))
m.create_all(engine)
添加 IDENTITY
关键字到非主键列,请指定 True
对于 Column.autoincrement
所需的标志 Column
反对,并确保 Column.autoincrement
设置为 False
在任何整数主键列上::
m = MetaData()
t = Table('t', m,
Column('id', Integer, primary_key=True, autoincrement=False),
Column('x', Integer, autoincrement=True))
m.create_all(engine)
1.3 版后已移除: Sequence
指定标识特征是不推荐使用的,将在将来的版本中删除。请使用 mssql_identity_start
和 mssql_identity_increment
参数记录在 自动增量行为/标识列 .
注解
表上只能有一个标识列。使用时 autoincrement=True
要启用IDENTITY关键字,SQLAlchemy不会防止同时指定选项的多个列。SQL Server数据库将拒绝 CREATE TABLE
语句。
注解
试图为标记有标识的列提供值的INSERT语句将被SQL Server拒绝。要接受该值,必须启用会话级选项“设置标识插入”。当使用核心时,SQLAlchemy SQL Server方言将自动执行此操作 Insert
构造;如果执行为标识列指定了一个值,则将为该语句的调用范围启用“identityu insert”选项。但是,此方案的性能不高,不应依赖于正常使用。如果表在其整数主键列中实际上不需要标识行为,则在创建表时应通过确保 autoincrement=False
被设置。
对“开始”和“增量”值的特定控制 IDENTITY
发电机使用 mssql_identity_start
和 mssql_identity_increment
传递给的参数 Column
对象:
from sqlalchemy import Table, Integer, Column
test = Table(
'test', metadata,
Column(
'id', Integer, primary_key=True, mssql_identity_start=100,
mssql_identity_increment=10
),
Column('name', String(20))
)
上面的创建表 Table
对象为:
CREATE TABLE test (
id INTEGER NOT NULL IDENTITY(100,10) PRIMARY KEY,
name VARCHAR(20) NULL,
)
处理 IDENTITY
插入时的列涉及两个关键技术。最常见的是能够获取给定的“最后插入的值” IDENTITY
列,在许多情况下,SQLAlchemy隐式执行的过程,最重要的是在ORM中。
获取此值的过程有几个变体:
在大多数情况下,返回与SQL Server上的insert语句一起使用,以获取新生成的主键值:
INSERT INTO t (x) OUTPUT inserted.id VALUES (?)
当返回不可用或已被禁用时,通过 implicit_returning=False
,要么 scope_identity()
函数或 @@identity
使用变量;行为因后端而异:
使用pyodbc时, ; select scope_identity()
将附加到insert语句的末尾;将获取第二个结果集以接收该值。给一张表格作为:
t = Table('t', m, Column('id', Integer, primary_key=True),
Column('x', Integer),
implicit_returning=False)
插入内容如下:
INSERT INTO t (x) VALUES (?); select scope_identity()
其他方言如pymsql将调用 SELECT scope_identity() AS lastrowid
在insert语句之后。如果旗 use_scope_identity=False
传递给 create_engine()
,声明 SELECT @@identity AS lastrowid
而是使用。
包含 IDENTITY
列将禁止显式引用标识列的INSERT语句。SQLAlchemy方言将检测使用核心创建的插入构造的时间 insert()
构造(不是纯字符串SQL),引用标识列,在这种情况下将发出 SET IDENTITY_INSERT ON
在插入声明程序之前,以及 SET IDENTITY_INSERT OFF
在执行之后。举个例子:
m = MetaData()
t = Table('t', m, Column('id', Integer, primary_key=True),
Column('x', Integer))
m.create_all(engine)
engine.execute(t.insert(), {'id': 1, 'x':1}, {'id':2, 'x':2})
上面的列将使用标识创建,但是我们发出的insert语句指定了显式值。在echo输出中,我们可以看到SQLAlchemy如何处理这一点:
CREATE TABLE t (
id INTEGER NOT NULL IDENTITY(1,1),
x INTEGER NULL,
PRIMARY KEY (id)
)
COMMIT
SET IDENTITY_INSERT t ON
INSERT INTO t (id, x) VALUES (?, ?)
((1, 1), (2, 2))
SET IDENTITY_INSERT t OFF
COMMIT
这是一个适用于测试和批量插入场景的辅助用例。
SQL Server支持 sqltypes.VARCHAR
和 sqltypes.NVARCHAR
数据类型,表示“可能的最大长度”。方言当前在基类型中将其处理为“无”的长度,而不是提供这些类型的方言特定版本,以便指定基类型,例如 VARCHAR(None)
可以在多个后端上假定“unengthed”行为,而不使用特定于方言的类型。
要生成最大长度的SQL Server varchar或nvarchar,请使用none::
my_table = Table(
'my_table', metadata,
Column('my_data', VARCHAR(None)),
Column('my_n_data', NVARCHAR(None))
)
字符串参数“collation”:指定的基本字符串类型支持字符排序规则:
from sqlalchemy import VARCHAR
Column('login', VARCHAR(32, collation='Latin1_General_CI_AS'))
当这样的列与 Table
,此列的create table语句将生成:
login VARCHAR(32) COLLATE Latin1_General_CI_AS NULL
MSSQL不支持limit或offset关键字。限制直接通过 TOP
Transact-SQL关键字:
select.limit
收益率:
SELECT TOP n
如果使用SQL Server 2005或更高版本,则可以通过 ROW_NUMBER OVER
构建。对于低于2005年的版本,使用偏移量的限制将失败。
所有SQL Server方言都支持通过方言特定参数设置事务隔离级别。 create_engine.isolation_level
被接受 create_engine()
以及 Connection.execution_options.isolation_level
传递给的参数 Connection.execution_options()
. 此功能通过发出命令来工作 SET TRANSACTION ISOLATION LEVEL <level>
对于每个新连接。
要设置隔离级别,请使用 create_engine()
::
engine = create_engine(
"mssql+pyodbc://scott:tiger@ms_2008",
isolation_level="REPEATABLE READ"
)
使用每个连接执行选项进行设置:
connection = engine.connect()
connection = connection.execution_options(
isolation_level="READ COMMITTED"
)
的有效值 isolation_level
包括:
AUTOCOMMIT
-pyodbc/pymssql特定
READ COMMITTED
READ UNCOMMITTED
REPEATABLE READ
SERIALIZABLE
SNAPSHOT
-特定于SQL Server
1.1 新版功能: 支持在Microsoft SQL Server上设置隔离级别。
1.2 新版功能: 添加自动提交隔离级别设置
MSSQL支持三个级别的列可空性。默认的可空性允许空值,并且在创建表构造中是显式的::
name VARCHAR(20) NULL
如果 nullable=None
如果指定,则不制定规范。换句话说,使用数据库的配置默认值。这将呈现:
name VARCHAR(20)
如果 nullable
是 True
或 False
那么这个列将是 NULL
或 NOT NULL
分别。
支持日期和时间。绑定参数根据大多数MSSQL驱动程序的要求转换为datetime.datetime()对象,如果需要,将从字符串中处理结果。日期和时间类型不适用于MSSQL2005和以前版本-如果检测到低于2008的服务器版本,这些类型的DDL将作为日期时间发出。
每 SQL Server 2012/2014 Documentation , the NTEXT
, TEXT
和 IMAGE
数据类型将在将来的版本中从SQL Server中删除。SQLAlchemy通常将这些类型与 UnicodeText
, Text
和 LargeBinary
数据类型。
为了适应这种变化,新的标志 deprecate_large_types
添加到方言中,如果用户未进行其他设置,则将根据正在使用的服务器版本检测自动进行设置。此标志的行为如下:
当此标志为 True
, the UnicodeText
, Text
和 LargeBinary
当用于呈现DDL时,数据类型将呈现这些类型 NVARCHAR(max)
, VARCHAR(max)
和 VARBINARY(max)
,分别。这是添加此标志后的新行为。
当此标志为 False
, the UnicodeText
, Text
和 LargeBinary
当用于呈现DDL时,数据类型将呈现这些类型 NTEXT
, TEXT
和 IMAGE
,分别。这是这些类型的长期行为。
标志以值开头 None
,在建立数据库连接之前。如果方言用于呈现没有设置标志的DDL,则解释为 False
.
在第一次连接时,方言将检测SQL Server 2012或更高版本是否在使用中;如果标志仍在 None
它把它设置为 True
或 False
基于是否检测到2012或更高版本。
标志可以设置为 True
或 False
创建方言时,通常通过 create_engine()
::
eng = create_engine("mssql+pymssql://user:pass@host/db",
deprecate_large_types=True)
在所有SQLAlchemy版本中,通过使用大写类型对象,可以完全控制呈现“旧”类型还是“新”类型: NVARCHAR
, VARCHAR
, types.VARBINARY
, TEXT
, mssql.NTEXT
, mssql.IMAGE
将始终保持固定,并始终准确输出该类型。
1.0.0 新版功能.
SQL Server模式有时需要对其“模式”限定符使用多个部分,即将数据库名称和所有者名称作为单独的标记,例如 mydatabase.dbo.some_table
. 这些多部分名称可以使用 Table.schema
的参数 Table
::
Table(
"some_table", metadata,
Column("q", String(50)),
schema="mydatabase.dbo"
)
在执行表或组件反射等操作时,包含点的架构参数将被拆分为单独的“数据库”和“所有者”组件,以便正确查询SQL Server信息架构表,因为这两个值是单独存储的。此外,在为DDL或SQL呈现模式名称时,这两个组件将分别引用区分大小写的名称和其他特殊字符。给出如下参数:
Table(
"some_table", metadata,
Column("q", String(50)),
schema="MyDataBase.dbo"
)
上面的模式将呈现为 [MyDataBase].dbo
以及在反射中,将使用“dbo”作为所有者,“mydatabase”作为数据库名称进行反射。
要控制模式名称如何分解为数据库/所有者,请在名称中指定方括号(在SQL Server中,方括号引用字符)。以下“业主”将被视为 MyDataBase.dbo
“数据库”将为无:
Table(
"some_table", metadata,
Column("q", String(50)),
schema="[MyDataBase.dbo]"
)
要使用特殊字符或嵌入点分别指定数据库和所有者名称,请使用两组括号:
Table(
"some_table", metadata,
Column("q", String(50)),
schema="[MyDataBase.Period].[MyOwner.Dot]"
)
在 1.2 版更改: 现在,SQL Server方言将括号视为标识符限定符,将模式拆分为单独的数据库和所有者标记,以允许在任一名称中使用点。
MSSQL方言的非常旧的版本引入了这样的行为:当在select语句中使用模式限定表时,该表将自动别名;给定一个表:
account_table = Table(
'account', metadata,
Column('id', Integer, primary_key=True),
Column('info', String(100)),
schema="customer_schema"
)
这种传统的呈现模式假定“customer_schema.account”不会被SQL语句的所有部分接受,如下所示:
>>> eng = create_engine("mssql+pymssql://mydsn", legacy_schema_aliasing=True)
>>> print(account_table.select().compile(eng))
SELECT account_1.id, account_1.info
FROM customer_schema.account AS account_1
默认情况下,此行为模式现在处于关闭状态,因为它似乎没有任何作用;但是,在遗留应用程序依赖它的情况下,可以使用 legacy_schema_aliasing
参数 create_engine()
如上图所示。
在 1.1 版更改: 这个 legacy_schema_aliasing
版本1.0.5中引入的标志,允许禁用模式的遗留模式,现在默认为false。
MSSQL方言通过 mssql_clustered
选择权。此选项可用于 Index
, UniqueConstraint
. 和 PrimaryKeyConstraint
.
要生成聚集索引,请执行以下操作:
Index("my_index", table.c.x, mssql_clustered=True)
它将索引呈现为 CREATE CLUSTERED INDEX my_index ON table (x)
.
要生成群集主键,请使用:
Table('my_table', metadata,
Column('x', ...),
Column('y', ...),
PrimaryKeyConstraint("x", "y", mssql_clustered=True))
例如,它将表呈现为:
CREATE TABLE my_table (x INTEGER NOT NULL, y INTEGER NOT NULL,
PRIMARY KEY CLUSTERED (x, y))
类似地,我们可以使用以下方法生成集群唯一约束:
Table('my_table', metadata,
Column('x', ...),
Column('y', ...),
PrimaryKeyConstraint("x"),
UniqueConstraint("y", mssql_clustered=True),
)
要显式请求非聚集主键(例如,当需要单独的聚集索引时),请使用:
Table('my_table', metadata,
Column('x', ...),
Column('y', ...),
PrimaryKeyConstraint("x", "y", mssql_clustered=False))
例如,它将表呈现为:
CREATE TABLE my_table (x INTEGER NOT NULL, y INTEGER NOT NULL,
PRIMARY KEY NONCLUSTERED (x, y))
在 1.1 版更改: 这个 mssql_clustered
选项现在默认为无,而不是假。 mssql_clustered=False
现在显式地呈现非聚集子句,而none则完全省略clustered子句,从而使SQL Server默认值生效。
除了集群之外,MSSQL方言还支持 Index
.
这个 mssql_include
选项呈现给定字符串名称的include(colname)::
Index("my_index", table.c.x, mssql_include=['y'])
将索引呈现为 CREATE INDEX my_index ON table (x) INCLUDE (y)
MSSQL支持在数据库级别设置兼容级别的概念。例如,这允许在SQL2005数据库服务器上运行与SQL2000兼容的数据库。 server_version_info
将始终返回数据库服务器版本信息(在本例中是SQL2005),而不是兼容级别信息。因此,如果在向后兼容模式下运行,则SQLAlchemy可能会尝试使用数据库服务器无法分析的T-SQL语句。
默认情况下,SQLAlchemy使用插入的输出通过标识列或其他服务器端默认值获取新生成的主键值。MS-SQL不允许在具有触发器的表上使用插入的输出。要禁用按表插入的输出,请指定 implicit_returning=False
对于每一个 Table
触发条件:
Table('mytable', metadata,
Column('id', Integer, primary_key=True),
# ...,
implicit_returning=False
)
声明形式:
class MyClass(Base):
# ...
__table_args__ = {'implicit_returning':False}
也可以使用 implicit_returning=False
争论 create_engine()
.
SQL Server驱动程序返回更新或删除语句中更新的行数的能力可能有限。
在撰写本文时,当使用插入的输出时,pyodbc驱动程序无法返回行数。这会影响SQLAlchemy ORM的版本控制功能,在许多情况下,服务器端的值生成器正在使用中,当版本控制操作可以成功时,ORM不能总是检查更新或删除语句是否与预期的行数匹配,这就是它验证版本标识符是否匹配的方式。出现这种情况时,将发出警告,但操作将继续。
通过设置 Table.implicit_returning
旗到 False
关于某一特定 Table
,在声明式中如下所示:
class MyTable(Base):
__tablename__ = 'mytable'
id = Column(Integer, primary_key=True)
stuff = Column(String(10))
timestamp = Column(TIMESTAMP(), default=text('DEFAULT'))
__mapper_args__ = {
'version_id_col': timestamp,
'version_id_generator': False,
}
__table_args__ = {
'implicit_returning': False
}
SQL Server有一个默认的事务隔离模式,该模式锁定整个表,并导致即使是轻微并发的应用程序具有长时间持有的锁和频繁的死锁。建议将数据库作为一个整体启用快照隔离,以获得现代级别的并发支持。这是通过在SQL提示下执行以下alter database命令来实现的:
ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON
ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON
有关SQL Server快照隔离的背景,请访问http://msdn.microsoft.com/en-us/library/ms175095.aspx。
与所有的SQLAlchemy方言一样,已知对SQL Server有效的所有大写类型都可以从顶级方言导入,无论它们是否源自 sqlalchemy.types
或者来自当地方言:
from sqlalchemy.dialects.mssql import \
BIGINT, BINARY, BIT, CHAR, DATE, DATETIME, DATETIME2, \
DATETIMEOFFSET, DECIMAL, FLOAT, IMAGE, INTEGER, MONEY, \
NCHAR, NTEXT, NUMERIC, NVARCHAR, REAL, SMALLDATETIME, \
SMALLINT, SMALLMONEY, SQL_VARIANT, TEXT, TIME, \
TIMESTAMP, TINYINT, UNIQUEIDENTIFIER, VARBINARY, VARCHAR
特定于SQL Server或具有特定于SQL Server的构造参数的类型如下:
sqlalchemy.dialects.mssql.
BIT
¶基地: sqlalchemy.types.TypeEngine
__init__
¶继承 __init__
属性 object
初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
CHAR
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶SQL字符类型。
__init__
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶继承 __init__()
方法 String
创建字符串保持类型。
length¶ -- 可选,用于DDL和CAST表达式的列的长度。如果没有,可以安全地省略 CREATE TABLE
将发布。某些数据库可能需要 length
在DDL中使用,并在 CREATE TABLE
如果 VARCHAR
不包括长度。该值是否解释为字节或字符是特定于数据库的。
collation¶ -- 可选,用于DDL和CAST表达式的列级排序规则。使用sqlite、mysql和postgresql支持的collate关键字进行渲染。例如::>>>从sqlachemy import cast,select,string>>print select( [cast('some string', String(collation='utf8'))] )选择CAST(:param_1 as varchar collate utf8)as anon_1
convert_unicode¶ -- 当设置为 True
, the String
类型将假定输入将作为python 2下的python unicode对象传递,结果将作为python unicode对象返回。在DBAPI在python 2下不支持pythonUnicode的罕见情况下,sqlachemy将在字符串上使用自己的编码器/解码器功能,参考 create_engine.encoding
参数参数传递给 create_engine()
作为编码。…已弃用::1.3 String.convert_unicode
参数已弃用,将在将来的版本中删除。所有现代DBAPI现在都直接支持PythonUnicode,而这个参数是不必要的。对于极为罕见的情况,python unicode将由sqlachemy在后端进行编码/解码, does 本机支持python unicode,字符串值 "force"
可以在此处传递,这将导致无条件使用SQLAlchemy的编码/解码服务。…注意::SQLAlchemy的unicode转换标志和特性只适用于python 2;在python 3中,所有字符串对象都是unicode对象。出于这个原因,以及事实上,几乎所有现代DBAPI现在都支持Unicode,即使在Python2下, String.convert_unicode
标志本身就是一个遗留功能。…注:在绝大多数情况下, Unicode
或 UnicodeText
数据类型应用于 Column
它希望存储非ASCII数据。这些数据类型将确保在数据库端使用正确的类型,并在Python2下设置正确的Unicode行为。…参阅: create_engine.convert_unicode
- Engine
宽参数
unicode_error¶ -- 可选,用于处理Unicode转换错误的方法。表现得像 errors
标准库的关键字参数 string.decode()
函数,要求 String.convert_unicode
设置为 "force"
…已弃用::1.3 String.unicode_errors
参数已弃用,将在将来的版本中删除。这个参数对于现代的python dbapis来说是不必要的,并且会显著降低性能。
sqlalchemy.dialects.mssql.
DATETIME2
(precision=None, **kw)¶基地: sqlalchemy.dialects.mssql.base._DateTimeBase
, sqlalchemy.types.DateTime
__init__
(precision=None, **kw)¶初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
DATETIMEOFFSET
(precision=None, **kwargs)¶基地: sqlalchemy.types.TypeEngine
__init__
(precision=None, **kwargs)¶初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
IMAGE
(length=None)¶基地: sqlalchemy.types.LargeBinary
__init__
(length=None)¶继承 __init__()
方法 LargeBinary
构造一个大二进制类型。
length¶ -- 可选,用于ddl语句中的列的长度,用于接受长度的二进制类型,例如mysql blob类型。
sqlalchemy.dialects.mssql.
MONEY
¶基地: sqlalchemy.types.TypeEngine
__init__
¶继承 __init__
属性 object
初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
NCHAR
(length=None, **kwargs)¶SQL NChar类型。
__init__
(length=None, **kwargs)¶继承 __init__()
方法 Unicode
创建一个 Unicode
对象。
参数与 String
,除了 convert_unicode
默认为 True
.
sqlalchemy.dialects.mssql.
NTEXT
(length=None, **kwargs)¶基地: sqlalchemy.types.UnicodeText
mssql ntext类型,用于长度不超过2^30个字符的Unicode文本。
__init__
(length=None, **kwargs)¶继承 __init__()
方法 UnicodeText
创建一个Unicode转换文本类型。
参数与 Text
,除了 convert_unicode
默认为 True
.
sqlalchemy.dialects.mssql.
NVARCHAR
(length=None, **kwargs)¶SQL nvarchar类型。
__init__
(length=None, **kwargs)¶继承 __init__()
方法 Unicode
创建一个 Unicode
对象。
参数与 String
,除了 convert_unicode
默认为 True
.
sqlalchemy.dialects.mssql.
REAL
(**kw)¶__init__
(**kw)¶构造一个浮点。
precision¶ -- 用于DDL的数字精度 CREATE TABLE
.
asdecimal¶ -- 与…相同的标志 Numeric
,但默认为 False
. 请注意,将此标志设置为 True
导致浮点转换。
decimal_return_scale¶ -- 从浮点转换为python小数时使用的默认小数位数。由于小数点不准确,浮点值通常要长得多,而且大多数浮点数据库类型没有“小数位数”的概念,因此默认情况下,浮点类型在转换时查找前十位小数。指定此值将覆盖该长度。注意,如果没有另外指定,mysql float类型(包括“scale”)将使用“scale”作为decimal_return_scale的默认值。…版本已添加::0.9.0
sqlalchemy.dialects.mssql.
ROWVERSION
(convert_int=False)¶基地: sqlalchemy.dialects.mssql.base.TIMESTAMP
实现SQL Server行版本类型。
rowversion数据类型是timestamp数据类型的SQL Server同义词,但是当前的SQL Server文档建议对新数据类型使用rowversion。
rowversion数据类型 not 从数据库中反射(例如自省)本身;返回的数据类型将为 mssql.TIMESTAMP
.
这是一个只读数据类型,不支持插入值。
1.2 新版功能.
sqlalchemy.dialects.mssql.
SMALLDATETIME
(timezone=False)¶基地: sqlalchemy.dialects.mssql.base._DateTimeBase
, sqlalchemy.types.DateTime
sqlalchemy.dialects.mssql.
SMALLMONEY
¶基地: sqlalchemy.types.TypeEngine
__init__
¶继承 __init__
属性 object
初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
SQL_VARIANT
¶基地: sqlalchemy.types.TypeEngine
__init__
¶继承 __init__
属性 object
初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
TEXT
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶SQL文本类型。
__init__
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶继承 __init__()
方法 String
创建字符串保持类型。
length¶ -- 可选,用于DDL和CAST表达式的列的长度。如果没有,可以安全地省略 CREATE TABLE
将发布。某些数据库可能需要 length
在DDL中使用,并在 CREATE TABLE
如果 VARCHAR
不包括长度。该值是否解释为字节或字符是特定于数据库的。
collation¶ -- 可选,用于DDL和CAST表达式的列级排序规则。使用sqlite、mysql和postgresql支持的collate关键字进行渲染。例如::>>>从sqlachemy import cast,select,string>>print select( [cast('some string', String(collation='utf8'))] )选择CAST(:param_1 as varchar collate utf8)as anon_1
convert_unicode¶ -- 当设置为 True
, the String
类型将假定输入将作为python 2下的python unicode对象传递,结果将作为python unicode对象返回。在DBAPI在python 2下不支持pythonUnicode的罕见情况下,sqlachemy将在字符串上使用自己的编码器/解码器功能,参考 create_engine.encoding
参数参数传递给 create_engine()
作为编码。…已弃用::1.3 String.convert_unicode
参数已弃用,将在将来的版本中删除。所有现代DBAPI现在都直接支持PythonUnicode,而这个参数是不必要的。对于极为罕见的情况,python unicode将由sqlachemy在后端进行编码/解码, does 本机支持python unicode,字符串值 "force"
可以在此处传递,这将导致无条件使用SQLAlchemy的编码/解码服务。…注意::SQLAlchemy的unicode转换标志和特性只适用于python 2;在python 3中,所有字符串对象都是unicode对象。出于这个原因,以及事实上,几乎所有现代DBAPI现在都支持Unicode,即使在Python2下, String.convert_unicode
标志本身就是一个遗留功能。…注:在绝大多数情况下, Unicode
或 UnicodeText
数据类型应用于 Column
它希望存储非ASCII数据。这些数据类型将确保在数据库端使用正确的类型,并在Python2下设置正确的Unicode行为。…参阅: create_engine.convert_unicode
- Engine
宽参数
unicode_error¶ -- 可选,用于处理Unicode转换错误的方法。表现得像 errors
标准库的关键字参数 string.decode()
函数,要求 String.convert_unicode
设置为 "force"
…已弃用::1.3 String.unicode_errors
参数已弃用,将在将来的版本中删除。这个参数对于现代的python dbapis来说是不必要的,并且会显著降低性能。
sqlalchemy.dialects.mssql.
TIME
(precision=None, **kwargs)¶__init__
(precision=None, **kwargs)¶初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
TIMESTAMP
(convert_int=False)¶基地: sqlalchemy.types._Binary
实现SQL Server时间戳类型。
注意这是 完全不同 而不是SQL Server不支持的SQL标准时间戳类型。它是只读数据类型,不支持插入值。
1.2 新版功能.
sqlalchemy.dialects.mssql.
TINYINT
¶__init__
¶继承 __init__
属性 object
初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
UNIQUEIDENTIFIER
¶基地: sqlalchemy.types.TypeEngine
__init__
¶继承 __init__
属性 object
初始化自身。请参阅帮助(键入(self))以获得准确的签名。
sqlalchemy.dialects.mssql.
VARCHAR
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶SQL varchar类型。
__init__
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶继承 __init__()
方法 String
创建字符串保持类型。
length¶ -- 可选,用于DDL和CAST表达式的列的长度。如果没有,可以安全地省略 CREATE TABLE
将发布。某些数据库可能需要 length
在DDL中使用,并在 CREATE TABLE
如果 VARCHAR
不包括长度。该值是否解释为字节或字符是特定于数据库的。
collation¶ -- 可选,用于DDL和CAST表达式的列级排序规则。使用sqlite、mysql和postgresql支持的collate关键字进行渲染。例如::>>>从sqlachemy import cast,select,string>>print select( [cast('some string', String(collation='utf8'))] )选择CAST(:param_1 as varchar collate utf8)as anon_1
convert_unicode¶ -- 当设置为 True
, the String
类型将假定输入将作为python 2下的python unicode对象传递,结果将作为python unicode对象返回。在DBAPI在python 2下不支持pythonUnicode的罕见情况下,sqlachemy将在字符串上使用自己的编码器/解码器功能,参考 create_engine.encoding
参数参数传递给 create_engine()
作为编码。…已弃用::1.3 String.convert_unicode
参数已弃用,将在将来的版本中删除。所有现代DBAPI现在都直接支持PythonUnicode,而这个参数是不必要的。对于极为罕见的情况,python unicode将由sqlachemy在后端进行编码/解码, does 本机支持python unicode,字符串值 "force"
可以在此处传递,这将导致无条件使用SQLAlchemy的编码/解码服务。…注意::SQLAlchemy的unicode转换标志和特性只适用于python 2;在python 3中,所有字符串对象都是unicode对象。出于这个原因,以及事实上,几乎所有现代DBAPI现在都支持Unicode,即使在Python2下, String.convert_unicode
标志本身就是一个遗留功能。…注:在绝大多数情况下, Unicode
或 UnicodeText
数据类型应用于 Column
它希望存储非ASCII数据。这些数据类型将确保在数据库端使用正确的类型,并在Python2下设置正确的Unicode行为。…参阅: create_engine.convert_unicode
- Engine
宽参数
unicode_error¶ -- 可选,用于处理Unicode转换错误的方法。表现得像 errors
标准库的关键字参数 string.decode()
函数,要求 String.convert_unicode
设置为 "force"
…已弃用::1.3 String.unicode_errors
参数已弃用,将在将来的版本中删除。这个参数对于现代的python dbapis来说是不必要的,并且会显著降低性能。
sqlalchemy.dialects.mssql.
XML
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶MSSQL XML类型。
这是一个用于反射的占位符类型,不包含任何Python端数据类型支持。它目前也不支持其他参数,例如“content”、“document”、“xml-schema-collection”。
1.1.11 新版功能.
__init__
(length=None, collation=None, convert_unicode=False, unicode_error=None, _warn_on_bytestring=False, _expect_unicode=False)¶继承 __init__()
方法 String
创建字符串保持类型。
length¶ -- 可选,用于DDL和CAST表达式的列的长度。如果没有,可以安全地省略 CREATE TABLE
将发布。某些数据库可能需要 length
在DDL中使用,并在 CREATE TABLE
如果 VARCHAR
不包括长度。该值是否解释为字节或字符是特定于数据库的。
collation¶ -- 可选,用于DDL和CAST表达式的列级排序规则。使用sqlite、mysql和postgresql支持的collate关键字进行渲染。例如::>>>从sqlachemy import cast,select,string>>print select( [cast('some string', String(collation='utf8'))] )选择CAST(:param_1 as varchar collate utf8)as anon_1
convert_unicode¶ -- 当设置为 True
, the String
类型将假定输入将作为python 2下的python unicode对象传递,结果将作为python unicode对象返回。在DBAPI在python 2下不支持pythonUnicode的罕见情况下,sqlachemy将在字符串上使用自己的编码器/解码器功能,参考 create_engine.encoding
参数参数传递给 create_engine()
作为编码。…已弃用::1.3 String.convert_unicode
参数已弃用,将在将来的版本中删除。所有现代DBAPI现在都直接支持PythonUnicode,而这个参数是不必要的。对于极为罕见的情况,python unicode将由sqlachemy在后端进行编码/解码, does 本机支持python unicode,字符串值 "force"
可以在此处传递,这将导致无条件使用SQLAlchemy的编码/解码服务。…注意::SQLAlchemy的unicode转换标志和特性只适用于python 2;在python 3中,所有字符串对象都是unicode对象。出于这个原因,以及事实上,几乎所有现代DBAPI现在都支持Unicode,即使在Python2下, String.convert_unicode
标志本身就是一个遗留功能。…注:在绝大多数情况下, Unicode
或 UnicodeText
数据类型应用于 Column
它希望存储非ASCII数据。这些数据类型将确保在数据库端使用正确的类型,并在Python2下设置正确的Unicode行为。…参阅: create_engine.convert_unicode
- Engine
宽参数
unicode_error¶ -- 可选,用于处理Unicode转换错误的方法。表现得像 errors
标准库的关键字参数 string.decode()
函数,要求 String.convert_unicode
设置为 "force"
…已弃用::1.3 String.unicode_errors
参数已弃用,将在将来的版本中删除。这个参数对于现代的python dbapis来说是不必要的,并且会显著降低性能。
Support for the Microsoft SQL Server database via the PyODBC driver.
Documentation and download information (if applicable) for PyODBC is available at: http://pypi.python.org/pypi/pyodbc/
此处的URL将转换为pyodbc连接字符串,详细信息请参见 ConnectionStrings .
基于DSN的连接是 首选 使用ODBC时的总体情况。基于DSN的基本连接如下所示:
engine = create_engine("mssql+pyodbc://scott:tiger@some_dsn")
上面的内容将把以下连接字符串传递给pyodbc::
dsn=mydsn;UID=user;PWD=pass
如果省略用户名和密码,DSN表单还将添加 Trusted_Connection=yes
ODBC字符串的指令。
基于主机名的连接是 不优选 但是,支持。必须显式指定ODBC驱动程序名称::
engine = create_engine("mssql+pyodbc://scott:tiger@myhost:port/databasename?driver=SQL+Server+Native+Client+10.0")
在 1.0.0 版更改: 基于主机名的pyodbc连接现在需要显式指定SQL Server驱动程序名。SQLAlchemy无法在此处选择最佳默认值,因为它根据平台和已安装的驱动程序而有所不同。
pyodbc方言解释的其他关键字将传递给 pyodbc.connect()
在DSN和主机名的情况下包括: odbc_autotranslate
, ansi
, unicode_results
, autocommit
.
pyodbc连接字符串也可以完全按照中指定的方式发送。 ConnectionStrings 使用参数输入驱动程序 odbc_connect
. 但是,delimeter必须是URL转义的,如下图所示,使用 urllib.parse.quote_plus
::
import urllib
params = urllib.parse.quote_plus("DRIVER={SQL Server Native Client 10.0};SERVER=dagger;DATABASE=test;UID=user;PWD=password")
engine = create_engine("mssql+pyodbc:///?odbc_connect=%s" % params)
pyodbc最适用于Microsoft ODBC驱动程序,特别是在Python2和Python3上的Unicode支持方面。
在Linux或OSX上使用freetds-odbc驱动程序和pyodbc是 not 推荐;在这一领域历史上有许多与Unicode相关的问题,包括在Microsoft为Linux和OSX提供ODBC驱动程序之前。既然微软为所有平台提供了驱动程序,为了支持pyodbc,建议使用这些驱动程序。Freetds对于非ODBC驱动程序(如pymsql)仍然是相关的,在这里它工作得很好。
pyodbc仅部分支持行数。参见注释 行数支持/ORM版本控制 有关使用ORM版本控制时的重要注意事项。
pyodbc驱动程序增加了对“快速执行管理”执行模式的支持,大大减少了dbapi的往返次数。 executemany()
使用Microsoft ODBC驱动程序时调用。通过设置标志启用该功能 .fast_executemany
当要使用ExecuteMany调用时,在DBAPI光标上。当 .fast_executemany
标志传递给 create_engine()
;请注意,为了使用此标志,ODBC驱动程序必须是Microsoft驱动程序::
engine = create_engine(
"mssql+pyodbc://scott:tiger@mssql2017:1433/test?driver=ODBC+Driver+13+for+SQL+Server",
fast_executemany=True)
1.3 新版功能.
参见
fast executemany -吉瑟布
Support for the Microsoft SQL Server database via the mxODBC driver.
Documentation and download information (if applicable) for mxODBC is available at: http://www.egenix.com/
mxodbc具有两种类型的语句执行,使用 cursor.execute()
和 cursor.executedirect()
方法(第二个方法是DBAPI规范的扩展)。前者使用特定于SQL Server本机客户机ODBC驱动程序sqlDescribeParam的特定API调用,而后者则不使用。
显然,当使用sqlDescribeParam时,mxodbc只会重复使用一个准备好的语句。准备好的语句重用的优点之一是性能。缺点是,sqlDescribeParam有一组有限的场景,在这些场景中,可以理解绑定参数,包括不能将它们放在函数调用的参数列表中、FROM之外的任何位置,甚至不能放在FROM子句内的子查询中,这使得在SELECT语句中使用绑定参数对于除了最简单的陈述。
因此,mxodbc方言默认仅对insert、update和delete语句使用“本机”模式,对所有其他语句使用转义字符串模式。
这种行为可以通过 execution_options()
使用 native_odbc_execute
值为的标志 True
或 False
,其中值为 True
将无条件地使用本机绑定参数和值 False
将无条件使用字符串转义参数。
通过pymssql驱动程序支持Microsoft SQL Server数据库。
Documentation and download information (if applicable) for pymssql is available at: http://pymssql.org/
pymsql是一个python模块,它在 FreeTDS . 兼容的版本可用于Linux、MacOSX和Windows平台。
此驱动程序的现代版本与来自Linux的SQL Server和Freetds非常兼容,强烈推荐使用。
Support for the Microsoft SQL Server database via the zxJDBC for Jython driver.
注解
当前版本的SQLAlchemy不支持Jython。zxjdbc方言应被视为实验性方言。
Drivers for this database are available at: http://jtds.sourceforge.net/
Support for the Microsoft SQL Server database via the adodbapi driver.
Documentation and download information (if applicable) for adodbapi is available at: http://adodbapi.sourceforge.net/
注解
此时未实现0.6及以上版本的SQLAlchemy方言。