Изглежда, че SQLAlchemy поддържа 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
>>>
Вижте как да използвате специфични за доставчиците типове тук:http ://docs.sqlalchemy.org/en/latest/core/type_basics.html#vendor-specific-types
Колкото и да си струва, да се опитваш да разработиш напълно неутрален за марката слой на база данни е трудно и рядко си струва усилията. Работих върху Zend Framework 1.0 преди няколко години и се опитах да създам общ пакет за тестване на модули за всички SQL бази данни, поддържани от тази рамка. Открих, че много малко типове данни се поддържат по един и същи начин във всички реализации на SQL, въпреки че всички твърдят, че поддържат стандарта ANSI/ISO SQL.
В крайна сметка трябва да разработите своя собствена йерархия на класовете за вашия слой данни и да приложите кода малко по-различно за всеки адаптер, специфичен за базата данни.
Актуализация:Мисля, че новините са по-добри, отколкото си мислим. Опитах този тест:
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)
След това проверих какво създава в 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
Така че той картографира общия String на SQLAlchemy тип данни към повече или по-малко подходящ MySQL тип данни.
За мен не е изненадващо, че използва по-големи типове данни, отколкото може да очакваме. MEDIUMTEXT поддържа 16MB в байтове , а не в знаци . Тъй като моят набор от знаци по подразбиране е многобайтовият utfmb4, максималната дължина на MEDIUMTEXT всъщност е много по-малко от 2^24 знака. Така че трябваше да го надстрои до LONGTEXT . Разбира се, 2^32 знака няма да се поберат в LONGTEXT или, но изглежда SQLAlchemy предполага, че все пак искате да създадете колона.
Все още мисля, че е трудно да се направи напълно неутрален по отношение на изпълнението код. Например, какво ще стане, ако искате да използвате някои функции на MySQL като опции на таблицата за машината за съхранение или специфични типове данни без общ еквивалент (например ENUM )?
