Échec de l'installation de Django, indiquant "DatabaseError: valeur trop longue pour le type caractère variable (50)"

Question

J'ai un projecteur (json) qui charge dans un environnement de développement mais ne le fait pas dans l'environnement serveur. L'erreur indique: "DatabaseError: value too long for type character varying(50)"

Mon environnement de développement est Windows & Postgres 8.4. Le serveur exécute Debian et Postgres 8.3. Le codage de la base de données est UTF8 dans les deux systèmes. C'est comme si les marqueurs Unicode de l'appareil comptaient comme des caractères sur le serveur et que certaines chaînes dépassaient la longueur maximale de leur champ. Cependant, cela ne se produit pas dans l'environnement de développement.

Answer 1

Eh bien, ce qui fait la différence, c'est le codage des bases de données de modèles. Sur le serveur de production, ils avaient un encodage ascii alors que sur la boîte de dev, c'est utf-8.

Par défaut, postgres crée une base de données à l'aide du template1. Ma compréhension est que si son encodage n'est pas utf-8, alors la base de données que vous créez aura ce problème, même si vous le créez avec l'encodage utf-8. Par conséquent je l'ai laissé tomber et l'ai recréé avec son jeu d'encodage à UTF8. L'extrait fait en dessous (tiré de here):

psql -U postgres 

UPDATE pg_database SET datallowconn = TRUE where datname = 'template0'; 
\c template0 
UPDATE pg_database SET datistemplate = FALSE where datname = 'template1'; 
drop database template1; 
create database template1 with template = template0 encoding = 'UNICODE'; 
UPDATE pg_database SET datistemplate = TRUE where datname = 'template1'; 
\c template1 
UPDATE pg_database SET datallowconn = FALSE where datname = 'template0'; 

maintenant les charges de fixation en douceur.

Answer 2

Obtenez la véritable requête SQL sur les deux systèmes et voir ce qui est différent.

Answer 3

Mise à jour: 50 limite char is now 255 dans Django 1.8

-

réponse originale:

Je viens de rencontrer cet après-midi, aussi, et j'ai une solution (de toutes sortes)

Cette post here impliquait que c'est un bug de Django à faire avec la longueur de la valeur autorisée pour auth_permission. En creusant plus loin cette idée, comme le fait this Django ticket (même si c'est d'abord lié à MySQL).

Fondamentalement, un nom d'autorisation est créé en fonction du verbose_name d'un modèle plus une chaîne d'autorisation descriptive, et qui peut déborder de plus de 50 caractères autorisés dans auth.models.Permission.name.

Pour citer un commentaire sur le billet Django:

The longest prefixes for the string value in the column auth_permission.name are "Can change " and "Can delete ", both with 11 characters. The column maximum length is 50 so the maximum length of Meta.verbose_name is 39.

Une solution serait de pirater cette colonne pour supporter> 50 caractères (idéalement par une migration Sud, dis-je, de sorte qu'il est facile à répéter) mais Le correctif le plus rapide et le plus fiable auquel je pouvais penser était simplement de raccourcir ma définition de verbose_name extra-longue (de 47 caractères dans le verbose_name à environ 20). Tout fonctionne bien maintenant.

Answer 4

Pour information: J'ai aussi eu cette erreur

DatabaseError: value too long for type character varying(10) 

Il semble que j'écrivais des données sur la limite de 10 pour un champ.Je l'ai fixé en augmentant la taille d'un CharField de 10 à 20

J'espère que cela aide

Answer 5

Comme @stevejalim dit, il est tout à fait possible que la auth_permission.name colonne est le problème avec une longueur de 50, vous vérifiez ce avec \ d + auth_permission dans le shell de postgres. Dans mon cas, c'est le problema, donc quand je charge les appareils de modèles django je suis arrivé « DatabaseError: valeur trop longue pour caractère de type variable (50) », puis changer le modèle d'autorisation de django.contrib.auth est compliquée, donc ... simple solution a été effectuer une migration sur le modèle d'autorisation, j'ai fait cette commande ALTER TABLE auth_permission ALTER COLUMN name TYPE VARCHAR(100); en cours d'exécution dans la coquille de postgres, cela fonctionne pour moi.

crédits pour this comment

Answer 6

Vous pouvez faire Django utiliser des champs plus pour ce modèle singe-patcher le modèle avant de l'utiliser pour créer les tables de base de données. Dans "manage.py", le changement:

if __name__ == "__main__": 
    execute_manager(settings) 

à:

from django.contrib.auth.models import Permission 
if __name__ == "__main__": 
    # Patch the field width to allow for our long model names 
    Permission._meta.get_field('name').max_length=200 
    Permission._meta.get_field('codename').max_length=200 
    execute_manager(settings) 

Cette modifie les options sur le terrain avant (par exemple) manage.py syncdb est exécuté, de sorte que la table a databate belle large varchar() des champs. Vous n'avez pas besoin de le faire lorsque vous appelez votre application, car vous ne tentez jamais de modifier la table des autorisations en cours d'exécution.