.. seealso::
- :ref:`mypy_toplevel`
+ mypy_toplevel -- section was removed
.. changelog::
:version: 1.4.52
.. seealso::
- :ref:`mypy_declarative_mixins`
+ mypy_declarative_mixins -- section was removed
.. change::
.. seealso::
- :ref:`mypy_toplevel`
+ mypy_toplevel -- section was removed
.. change::
:tags: bug, sql
:class:`_orm.Mapped` which link to constructs such as :func:`_orm.relationship`
will raise errors in Python, as they suggest mis-configurations.
-SQLAlchemy applications that use the :ref:`Mypy plugin <mypy_toplevel>` with
+SQLAlchemy applications that use the Mypy plugin with
explicit annotations that don't use :class:`_orm.Mapped` in their annotations
are subject to these errors, as would occur in the example below::
~~~~~~~~~~~~~~~~~~~~~~
SQLAlchemy 1.4 introduced the first SQLAlchemy-native ORM typing support
-using a combination of sqlalchemy2-stubs_ and the :ref:`Mypy Plugin <mypy_toplevel>`.
+using a combination of sqlalchemy2-stubs_ and the Mypy Plugin.
In SQLAlchemy 2.0, the Mypy plugin **remains available, and has been updated
to work with SQLAlchemy 2.0's typing system**. However, it should now be
considered **deprecated**, as applications now have a straightforward path to adopting the
Using Legacy Mypy-Typed Models
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-SQLAlchemy applications that use the :ref:`Mypy plugin <mypy_toplevel>` with
+SQLAlchemy applications that use the Mypy plugin with
explicit annotations that don't use :class:`_orm.Mapped` in their annotations
are subject to errors under the new system, as such annotations are flagged as
errors when using constructs such as :func:`_orm.relationship`.
that all ORM annotations must make use of a generic container called
:class:`_orm.Mapped` to be properly annotated. Legacy SQLAlchemy mappings which
include explicit :pep:`484` typing annotations, such as those which use the
-:ref:`legacy Mypy extension <mypy_toplevel>` for typing support, may include
+legacy Mypy extension for typing support, may include
directives such as those for :func:`_orm.relationship` that don't include this
generic.
The above example maps the union of ``list[int]`` and ``list[str]`` to the Postgresql
:class:`_postgresql.JSONB` datatype, while naming a union of ``float,
-str, bool`` will match to the :class:`.JSON` datatype. An equivalent
+str, bool`` will match to the :class:`_types.JSON` datatype. An equivalent
union, stated in the :class:`_orm.Mapped` construct, will match into the
corresponding entry in the type map.
constraints, all participating ``CREATE TABLE`` statements must specify a
transactional engine, which in the vast majority of cases is ``InnoDB``.
+Partitioning can similarly be specified using similar options.
+In the example below the create table will specify ``PARTITION_BY``,
+``PARTITIONS``, ``SUBPARTITIONS`` and ``SUBPARTITION_BY``::
+
+ # can also use mariadb_* prefix
+ Table(
+ "testtable",
+ MetaData(),
+ Column("id", Integer(), primary_key=True, autoincrement=True),
+ Column("other_id", Integer(), primary_key=True, autoincrement=False),
+ mysql_partitions="2",
+ mysql_partition_by="KEY(other_id)",
+ mysql_subpartition_by="HASH(some_expr)",
+ mysql_subpartitions="2",
+ )
+
+This will render:
+
+.. sourcecode:: sql
+
+ CREATE TABLE testtable (
+ id INTEGER NOT NULL AUTO_INCREMENT,
+ other_id INTEGER NOT NULL,
+ PRIMARY KEY (id, other_id)
+ )PARTITION BY KEY(other_id) PARTITIONS 2 SUBPARTITION BY HASH(some_expr) SUBPARTITIONS 2
Case Sensitivity and Table Reflection
-------------------------------------
The :func:`_orm.declarative_mixin` decorator currently does not modify
the given class in any way; it's current purpose is strictly to assist
- the :ref:`Mypy plugin <mypy_toplevel>` in being able to identify
+ the Mypy plugin in being able to identify
SQLAlchemy declarative mixin classes when no other context is present.
.. versionadded:: 1.4.6
:ref:`orm_mixins_toplevel`
- :ref:`mypy_declarative_mixins` - in the
- :ref:`Mypy plugin documentation <mypy_toplevel>`
-
""" # noqa: E501
return cls
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
