On dirait que SQLAlchemy prend en charge 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
>>>
Découvrez comment utiliser les types spécifiques au fournisseur ici :http ://docs.sqlalchemy.org/en/latest/core/type_basics.html#vendor-specific-types
Pour ce que ça vaut, essayer de développer une couche de base de données totalement indépendante de la marque est difficile et vaut rarement la peine. J'ai travaillé sur le Zend Framework 1.0 il y a quelques années, et j'ai essayé de créer une suite de tests unitaires génériques pour toutes les bases de données SQL supportées par ce framework. J'ai constaté que très peu de types de données sont pris en charge de la même manière dans toutes les implémentations de SQL, bien qu'ils prétendent tous prendre en charge la norme ANSI/ISO SQL.
En fin de compte, vous devez développer votre propre hiérarchie de classes pour votre couche de données et implémenter le code légèrement différemment pour chaque adaptateur spécifique à la base de données.
Mise à jour :Je pense que les nouvelles sont meilleures que nous ne le pensons. J'ai essayé ce test :
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)
Ensuite, j'ai vérifié pour voir ce qu'il a fini par créer dans la base de données 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
Donc, il mappe le String générique de SQLAlchemy type de données en un type de données MySQL plus ou moins approprié.
Il n'est pas surprenant pour moi qu'il ait utilisé des types de données plus volumineux que ce à quoi nous pourrions nous attendre. Le MEDIUMTEXT prend en charge 16 Mo en octets , pas en caractères . Parce que mon jeu de caractères par défaut est l'utfmb4 multi-octets, la longueur maximale de MEDIUMTEXT est en fait beaucoup moins que 2^24 caractères. Il a donc dû le mettre à niveau vers LONGTEXT . Bien sûr, 2^32 caractères ne rentreront pas dans LONGTEXT soit, mais il semble que SQLAlchemy suppose que vous voulez quand même créer une colonne.
Je pense toujours qu'il est difficile de faire du code totalement neutre en termes d'implémentation. Par exemple, que se passe-t-il si vous souhaitez utiliser certaines fonctionnalités de MySQL telles que les options de table pour le moteur de stockage ou des types de données spécifiques sans équivalent générique (par exemple, ENUM ) ?
