Wygląda na to, że SQLAlchemy obsługuje 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
>>>
Zobacz, jak używać typów specyficznych dla dostawcy tutaj:http ://docs.sqlalchemy.org/en/latest/core/type_basics.html#typy-dostawcy
Co jest warte, próba stworzenia całkowicie neutralnej dla marki warstwy bazy danych jest trudna i rzadko warta wysiłku. Kilka lat temu pracowałem nad Zend Framework 1.0 i próbowałem stworzyć ogólny zestaw testów jednostkowych dla wszystkich baz danych SQL obsługiwanych przez ten framework. Odkryłem, że bardzo niewiele typów danych jest obsługiwanych w ten sam sposób we wszystkich implementacjach SQL, mimo że wszystkie twierdzą, że obsługują standard ANSI/ISO SQL.
Ostatecznie musisz opracować własną hierarchię klas dla warstwy danych i zaimplementować kod nieco inaczej dla każdego adaptera specyficznego dla bazy danych.
Aktualizacja:Myślę, że wiadomości są lepsze niż nam się wydaje. Próbowałem tego testu:
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)
Następnie sprawdziłem, co ostatecznie utworzył w bazie danych 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
Odwzorowuje więc ogólny String SQLAlchemy typ danych na mniej więcej odpowiedni typ danych MySQL.
Nie dziwi mnie, że używał większych typów danych, niż moglibyśmy się spodziewać. MEDIUMTEXT obsługuje 16 MB w bajtach , a nie w znakach . Ponieważ mój domyślny zestaw znaków to wielobajtowy utfmb4, maksymalna długość MEDIUMTEXT jest w rzeczywistości znacznie mniej niż 2^24 znaki. Musiał więc zaktualizować go do LONGTEXT . Oczywiście 2^32 znaki nie zmieszczą się w LONGTEXT albo, ale wygląda na to, że SQLAlchemy zakłada, że i tak chcesz utworzyć kolumnę.
Nadal uważam, że ciężko jest wykonać kod całkowicie neutralny pod względem implementacji. Na przykład, co zrobić, jeśli chcesz użyć niektórych funkcji MySQL, takich jak opcje tabel dla silnika pamięci masowej lub określone typy danych bez ogólnego odpowiednika (na przykład ENUM )?
