Parece que SQLAlchemy suporta 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
>>>
Veja como usar tipos específicos do fornecedor aqui:http ://docs.sqlalchemy.org/en/latest/core/type_basics.html#vendor-specific-types
Vale a pena tentar desenvolver uma camada de banco de dados totalmente neutra em termos de marca é difícil e raramente vale o esforço. Trabalhei no Zend Framework 1.0 alguns anos atrás e tentei criar um conjunto genérico de testes unitários para todos os bancos de dados SQL suportados por esse framework. Descobri que muito poucos tipos de dados são suportados da mesma maneira em todas as implementações do SQL, apesar de todos alegarem oferecer suporte ao padrão ANSI/ISO SQL.
Em última análise, você precisa desenvolver sua própria hierarquia de classes para sua camada de dados e implementar o código de maneira um pouco diferente para cada adaptador específico do banco de dados.
Atualização:acho que as notícias são melhores do que pensamos. Eu tentei este teste:
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)
Então eu verifiquei para ver o que acabou criando no banco de dados 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
Portanto, mapeia a
String genérica do SQLAlchemy tipo de dados para um tipo de dados MySQL mais ou menos apropriado. Não é surpreendente para mim que ele usou tipos de dados maiores do que poderíamos esperar. O
MEDIUMTEXT suporta 16 MB em bytes , não em caracteres . Como meu conjunto de caracteres padrão é o utfmb4 de vários bytes, o comprimento máximo de MEDIUMTEXT é realmente muito menos do que 2^24 caracteres. Então, ele teve que atualizá-lo para LONGTEXT . Claro, 2^32 caracteres não cabem em LONGTEXT também, mas parece que o SQLAlchemy assume que você pretende criar uma coluna de qualquer maneira. Eu ainda acho que é difícil fazer um código totalmente neutro em termos de implementação. Por exemplo, e se você quiser usar alguns recursos do MySQL como opções de tabela para o mecanismo de armazenamento ou tipos de dados específicos sem equivalente genérico (por exemplo,
ENUM )? 
