Django syncdb sur les données initiales SQL en utilisant des rendements PostgreSQL « colonne ... n'existe pas »

Question

Plate-forme: Python 2.5, racine de développement de Django, PostgreSQL 8.4, Windows Vista Édition Intégrale SP2. Procédure: Django Documentation, Version 1.0, le texte du lien , Section 34.2, Fournir des données initiales SQL.

CODE:

models.py:  

class aisc_customary(models.Model):
    MTYPE                 = models.CharField(max_length=4, editable=False, 
                                help_text="Shape type, e.g. W, C, L, etc.")
    EDI_STD_NOMENCLATURE  = models.CharField(max_length=26, editable=False, 
                                help_text="EDI shape designation")
    AISC_MANUAL_LABEL     = models.CharField(max_length=26, editable=False, primary_key=True, 
                                help_text="AISC Manual label")
    T_F                   = models.CharField(max_length=1, editable=False, 
                                help_text="Special note flag, T or F")
    W                     = models.FloatField(editable=False, 
                                help_text="Nominal weight, lbs/ft")
... (45 more FloatFields)


application1/sql/aisc_customary.sql:  

    INSERT INTO application1_aisc_customary (MTYPE, EDI_STD_NOMENCLATURE, AISC_MANUAL_LABEL, T_F, W, A, D, HT, OD, BF, B, ID, TW, TF, T, TNOM, TDES, KDES, KDET, K1, X, Y , E0, XP, YP, BF_2TF, B_T, H_TW, H_T, D_T, IX, ZX, SX, RX, IY, ZY, SY, RY, RZ, J, CW, C, WNO, SW, QF, QW, RO, H, TAN_ALPHA, QS) VALUES ('W', 'W44X335', 'W44X335', 'F', 335, 98.5, 44.0, 0, 0, 15.9, 0, 0, 1.03, 1.77, 0, 0, 0.00, 2.56, 2.63, 1.31, 0.00, 0.00, 0.00, 0.00, 0.00, 4.50, 0.00, 38.0, 0.00, 0.00, 31100, 1620, 1410, 17.8, 1200, 236, 150, 3.49, 0.00, 74.7, 535000, 0.00, 168, 1180, 278, 805, 0.00, 0.00, 0.00, 0.00);
    INSERT INTO application1_aisc_customary (MTYPE, EDI_STD_NOMENCLATURE, AISC_MANUAL_LABEL, T_F, W, A, D, HT, OD, BF, B, ID, TW, TF, T, TNOM, TDES, KDES, KDET, K1, X, Y , E0, XP, YP, BF_2TF, B_T, H_TW, H_T, D_T, IX, ZX, SX, RX, IY, ZY, SY, RY, RZ, J, CW, C, WNO, SW, QF, QW, RO, H, TAN_ALPHA, QS) VALUES ('W', 'W44X290', 'W44X290', 'F', 290, 85.4, 43.6, 0, 0, 15.8, 0, 0, 0.865, 1.58, 0, 0, 0.00, 2.36, 2.44, 1.25, 0.00, 0.00, 0.00, 0.00, 0.00, 5.02, 0.00, 45.0, 0.00, 0.00, 27000, 1410, 1240, 17.8, 1040, 205, 132, 3.49, 0.00, 50.9, 461000, 0.00, 166, 1040, 248, 701, 0.00, 0.00, 0.00, 0.00);
    INSERT INTO application1_aisc_customary (MTYPE, EDI_STD_NOMENCLATURE, AISC_MANUAL_LABEL, T_F, W, A, D, HT, OD, BF, B, ID, TW, TF, T, TNOM, TDES, KDES, KDET, K1, X, Y , E0, XP, YP, BF_2TF, B_T, H_TW, H_T, D_T, IX, ZX, SX, RX, IY, ZY, SY, RY, RZ, J, CW, C, WNO, SW, QF, QW, RO, H, TAN_ALPHA, QS) VALUES ('W', 'W44X262', 'W44X262', 'F', 262, 76.9, 43.3, 0, 0, 15.8, 0, 0, 0.785, 1.42, 0, 0, 0.00, 2.20, 2.25, 1.19, 0.00, 0.00, 0.00, 0.00, 0.00, 5.57, 0.00, 49.6, 0.00, 0.00, 24100, 1270, 1110, 17.7, 923, 182, 117, 3.47, 0.00, 37.3, 405000, 0.00, 165, 928, 223, 630, 0.00, 0.00, 0.00, 0.00);

... (1965 more lines like this)

serveur de développement de Django fonctionne très bien et le serveur PostgreSQL fonctionne et répond aux questions sur les données d'autres modèles lorsque le fichier de données initial gênant est retiré de son chemin d'accès standard.

Avec les versions précédentes de mauvaises tables déposées à l'aide pgAdmin III, commande de la console "python manage.py syncdb" donne cette erreur:

Création tableau application1_aisc_customary Installation de SQL personnalisé pour le modèle application1.aisc_customary Échec de l'installation SQL personnalisé pour le modèle application1.aisc_customary: colonne « mtype » de relation « application1_aisc_customary » n'existe pas LIGNE 1: INSERT INTO application1_aisc_customary (MTYPE, EDI_STD_NOME ...

A points de carat en M de MTYPE. L'erreur nonobstant, la colonne (majuscules) MTYPE fait existe, comme on peut le voir en utilisant pgAdmin III. Notez que Django admin rapporte la table, mais il n'a pas les enregistrements.

J'ai essayé unicode et ANSI SQL pour le codage, la prise éditable = False hors les attributs modèle, et inférieur noms de cas pour tout, mais les attributs de modèle. Peut-être que je manque une instruction SQL préparatoire. Je suppression. Je serais extrêmement reconnaissant pour une réponse éclairante. Merci d'avance pour votre aide.

21/09/09: Pour mémoire, la réponse de Zalew est correcte. les noms de champs minuscules sont nécessaires. Je devais aussi changer le nom du champ, id (diamètre intérieur) à I_d afin de corriger le conflit évident avec la clé primaire. J'ai changé od à o_d pour correspondre. Problème résolu.

Answer 1

J'ai couru un test, avec le même résultat que vous. U doit utiliser les noms de champs minuscules de sorte qu'il fonctionne. Cependant, u n'ont pas de réécrire le SQL, peut laisser en majuscules dans le sql, ayant minuscules dans la définition du modèle et ça va fonctionner! qui est étrange parce que les noms de colonnes PGSQL sont sensibles à la casse. De l'autre côté, Django ne vous laissera pas avoir deux champs - un minuscule et une lettre majuscule avec le même nom (probablement bloqué en raison de divers systèmes db django fonctionne avec), alors ... encore étrange :)

Vous ne trouvez pas les détails de fond sur cette question cependant. Il suffit de suivre la convention en minuscule. Modifiez les champs de modèle pour abaisser et exécuter votre sql.

Answer 2

Hmm. Prise de vue dans l'obscurité, peut-être votre SQL personnalisé est en cours d'exécution avant que la table est créée via la commande syncdb?