Het lijkt erop dat SQLAlchemy LONGTEXT ondersteunt:
$ 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
>>>
Bekijk hier hoe u leverancierspecifieke typen kunt gebruiken:http ://docs.sqlalchemy.org/en/latest/core/type_basics.html#vendor-specific-types
Voor wat het waard is, proberen om een volledig merkneutrale databaselaag te ontwikkelen is moeilijk en zelden de moeite waard. Ik heb een paar jaar geleden aan het Zend Framework 1.0 gewerkt en ik heb geprobeerd een generieke unit-testsuite te maken voor alle SQL-databases die door dat framework worden ondersteund. Ik ontdekte dat maar heel weinig gegevenstypen op dezelfde manier worden ondersteund in alle implementaties van SQL, ondanks dat ze allemaal beweren de ANSI/ISO SQL-standaard te ondersteunen.
Uiteindelijk moet u uw eigen klassenhiërarchie voor uw gegevenslaag ontwikkelen en de code iets anders implementeren voor elke databasespecifieke adapter.
Update:Ik denk dat het nieuws beter is dan we denken. Ik heb deze test geprobeerd:
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)
Toen controleerde ik wat het uiteindelijk in de MySQL-database creëerde:
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
Dus het brengt SQLAlchemy's generieke String
in kaart gegevenstype naar een min of meer geschikt MySQL-gegevenstype.
Het is voor mij niet verrassend dat het grotere gegevenstypen gebruikte dan we zouden verwachten. De MEDIUMTEXT
ondersteunt 16 MB in bytes , niet in tekens . Omdat mijn standaardtekenset de multi-byte utfmb4 is, is de maximale lengte van MEDIUMTEXT
is eigenlijk veel minder dan 2^24 tekens. Dus het moest het upgraden naar LONGTEXT
. Natuurlijk passen 2^32 tekens niet in LONGTEXT
ook niet, maar het lijkt erop dat SQLAlchemy ervan uitgaat dat je toch een kolom wilt maken.
Ik denk nog steeds dat het moeilijk is om volledig implementatie-neutrale code te maken. Wat als u bijvoorbeeld bepaalde MySQL-functies wilt gebruiken, zoals tabelopties voor de opslagengine, of specifieke gegevenstypen zonder generiek equivalent (bijvoorbeeld ENUM
)?