2010-09-27 9 views
12

Ho un dispositivo (json) che carica nell'ambiente di sviluppo ma non riesce a farlo nell'ambiente server. L'errore dice: "DatabaseError: value too long for type character varying(50)"L'installazione Django fallisce, affermando "DatabaseError: valore troppo lungo per il tipo di carattere che varia (50)"

Il mio ambiente di sviluppo è Windows & Postgres 8.4. Il server esegue Debian e Postgres 8.3. La codifica del database è UTF8 in entrambi i sistemi.

È come se i marcatori Unicode nel dispositivo contano come caratteri sul server e fanno sì che alcune stringhe superino la lunghezza massima del loro campo. Tuttavia ciò non accade nell'ambiente dev ..

risposta

7

Bene, ciò che fa la differenza è la codifica dei database dei modelli. Sul server di produzione avevano la codifica ascii mentre sul dev box era utf-8.

Per impostazione predefinita, postgres crea un database utilizzando il modello1. La mia comprensione è che se la sua codifica non è utf-8, allora il database che creerai avrà questo problema, anche se lo crei con la codifica utf-8.

Pertanto l'ho rilasciato e lo ho ricreato con la sua codifica impostata su UTF8. Il frammento di seguito lo fa (tratto da 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'; 

Ora i carichi di fissaggio senza problemi.

+0

Grazie mille per questo - risolve l'intero problema di utf8 creazione di database da parte di django-testing. – RichVel

1

Ottieni la query SQL reale su entrambi i sistemi e scopri cosa è diverso.

+0

Un buon suggerimento +1, anche insieme a quanto sopra controlla i log del server. –

10

Aggiornamento: il limite di 50 car is now 255 in Django 1.8

-

risposta originale:

Ho appena incontrato questo pomeriggio, troppo, e ho una correzione (specie di)

Questo post here implica che si tratta di un errore di Django correlato alla lunghezza del valore consentito per auth_permission. Un ulteriore scavo conferma questa idea, così come lo è this Django ticket (anche se inizialmente è collegato a MySQL).

È fondamentalmente che un nome di autorizzazione viene creato in base al nome_prodotto di un modello più una stringa di autorizzazione descrittiva e che può eccedere su più di 50 caratteri consentiti in auth.models.Permission.name.

Per citare un commento sul biglietto 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.

Una soluzione potrebbe essere quella di incidere la colonna per sostenere> 50 caratteri (idealmente tramite una migrazione del Sud, dico, in modo che sia facilmente ripetibile), ma la soluzione più rapida e più affidabile che potessi pensare era semplicemente di rendere la mia definizione verbose_name extra-lunga molto più breve (da 47 caratteri nel file verbose_name a circa 20). Tutto funziona bene ora.

+0

Grazie per la risposta, ma la tua soluzione è limitata all'autore. Sfortunatamente qualsiasi campo char sembra essere in grado di generare un errore nel mio caso. – shanyu

+0

Non sarà nessun campo - saranno solo quelli con una lunghezza di 50 caratteri. Esegui syncdb con --verbosity = 2 per vedere quale soffoca in particolare, e questo potrebbe darti un indizio per vedere quali modelli stanno effettivamente causando il dolore. Inoltre, le impostazioni locali sono corrette sulla casella Debian? Ricordo che il valore predefinito è diverso da UTF8 o 16 a seconda di dove ci si trova (ad esempio, in GB, il valore predefinito è LATIN1, che esplode quando alimentato carattere non ASCII) –

1

Solo per informazioni: ho avuto anche questo errore

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

Sembra che stavo scrivendo i dati oltre il limite di 10 per un campo.Ho riparato aumentando la dimensione di un CharField 10-20

Spero che aiuta

1

Come @stevejalim dice, è molto probabile che l'auth_permission.name colonna è il problema con la lunghezza di 50, di verificare questo con \ d + auth_permission nella shell di postgres. Nel mio caso questo è il problema, quindi quando carico le fixture dei modelli django ho ottenuto "DatabaseError: value too long for type character varying (50)", quindi cambiare il modello di autorizzazione di django.contrib.auth è complicato, quindi ... il semplice soluzione è stata eseguita una migrazione sul modello di autorizzazione, l'ho fatto eseguendo il comando ALTER TABLE auth_permission ALTER COLUMN name TYPE VARCHAR(100); nella shell di Postgres, questo funziona per me.

crediti per this comment

1

possibile rendere il Django utilizzare più campi per questo modello scimmia-patching del modello prima di usarlo per creare le tabelle del database. In "manage.py", modificare:

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

a:

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) 

Questa modifica le opzioni sul campo prima di (diciamo) manage.py syncdb viene eseguito, in modo che il tavolo ha una bella databate varchar larga() campi. Non è necessario eseguire questa operazione quando si richiama l'app, poiché non si tenta mai di modificare la tabella delle autorizzazioni mentre è in esecuzione.

Problemi correlati