Parece que SQLAlchemy admite LONGTEXT:
$ python
Python 2.7.13 (default, Sep 29 2017, 15:31:18)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from sqlalchemy.dialects.mysql import LONGTEXT
>>>
Vea cómo usar tipos específicos de proveedores aquí:http ://docs.sqlalchemy.org/en/latest/core/type_basics.html#tipos-específicos-del-proveedor
Por si sirve de algo, tratar de desarrollar una capa de base de datos totalmente neutral para la marca es difícil y rara vez vale la pena el esfuerzo. Trabajé en Zend Framework 1.0 hace algunos años e intenté crear un conjunto genérico de pruebas unitarias para todas las bases de datos SQL compatibles con ese marco. Descubrí que muy pocos tipos de datos son compatibles de la misma manera en todas las implementaciones de SQL, a pesar de que todos afirman ser compatibles con el estándar ANSI/ISO SQL.
En última instancia, debe desarrollar su propia jerarquía de clases para su capa de datos e implementar el código de forma ligeramente diferente para cada adaptador específico de base de datos.
Actualización:creo que las noticias son mejores de lo que pensamos. Intenté esta prueba:
t2 = Table('t2', metadata,
Column('id', Integer, primary_key=True),
Column('t1', String(64000)),
Column('t2', String(16000000)),
Column('t3', String(4294000000)),
Column('t4', Text)
)
metadata.create_all(engine)
Luego revisé para ver qué terminó creando en la base de datos MySQL:
mysql> show create table t2;
CREATE TABLE `t2` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`t1` mediumtext,
`t2` longtext,
`t3` longtext,
`t4` text,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
Entonces mapea el String genérico de SQLAlchemy tipo de datos a un tipo de datos MySQL más o menos apropiado.
No me sorprende que usara tipos de datos más grandes de lo que podríamos esperar. El MEDIUMTEXT admite 16 MB en bytes , no en caracteres . Debido a que mi conjunto de caracteres predeterminado es utfmb4 de varios bytes, la longitud máxima de MEDIUMTEXT es en realidad mucho menos de 2^24 caracteres. Entonces tuvo que actualizarlo a LONGTEXT . Por supuesto, 2^32 caracteres no caben en LONGTEXT tampoco, pero parece que SQLAlchemy asume que quieres crear una columna de todos modos.
Sigo pensando que es difícil hacer un código totalmente neutral a la implementación. Por ejemplo, ¿qué sucede si desea utilizar algunas características de MySQL como opciones de tabla para el motor de almacenamiento o tipos de datos específicos sin equivalente genérico (por ejemplo, ENUM )?
