2009-09-20 3 views
1

Платформа: Python 2.5, корень разработки Django, PostgreSQL 8.4, Windows Vista Ultimate SP2. Процедура: Документация по Django, версия 1.0, link text, раздел 34.2, Предоставление исходных данных SQL.Django syncdb по исходным данным SQL с использованием результатов PostgreSQL «column ... не существует»

КОД:

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) 

сервер разработки Django работает отлично и сервер PostgreSQL работает и отвечает на запросы о данных других моделей, когда хлопотно исходный файл данных удаляется из стандартного пути.

В предыдущих версиях плохих таблиц отбрасывается при помощи pgAdmin III, консольную команду «питон manage.py SyncDB» дает эту ошибку:

Создание таблицы application1_aisc_customary Установка пользовательских SQL для application1.aisc_customary модели Не удалось установить пользовательские SQL для application1.aisc_customary модели: колонки "метатип" соотношения "application1_aisc_customary" не существует LINE 1: INSERT INTO application1_aisc_customary (MTYPE, EDI_STD_NOME ...

A точек каратов на М MTYPE ошибка несмотря, колонка. (верхний регистр) MTYPE делает есть, как видно, используя pgAdmin III. Обратите внимание, что администратор Django сообщает таблицу, но у нее нет записей.

Я пробовал кодировку Unicode и ANSI для SQL, принимая editable = False от атрибутов модели и имена нижних регистров для всего, кроме атрибутов модели. Возможно, мне не хватает подготовительной инструкции SQL. Я поражаю. Я был бы чрезвычайно благодарен за просветляющий ответ. Заранее спасибо за вашу помощь.

09/21/09: Для записи ответ зала верен. Нужны имена полей в нижнем регистре. Мне также пришлось изменить одно имя поля, id (внутренний диаметр) на i_d, чтобы исправить очевидный конфликт с первичным ключом. Я изменил od на o_d, чтобы соответствовать. Задача решена.

+0

это не решает ваш вопрос, но почему вы загружаете sql вместо крепления для исходных данных? – zalew

+0

Почему бы и нет? То есть, если это можно заставить работать! Переиздание исходной базы данных .csv, поскольку SQL было простым, со всеми именами слева и всеми значениями справа. Я сделал это с помощью макросов в Notepad ++. JSON или YAML, с другой стороны, потребует короткий сценарий Python. Это то, что я буду делать, хотя, если я не могу понять, что проблема с SQL. Мне неизвестно какое-либо большое преимущество для любого метода, учитывая, что я не предлагаю использовать собственный SQL через этот объект вне команд INSERT INTO. Возможно, SQL будет загружаться быстрее, но это разовая вещь, а не соображение. –

+0

уверен, я спросил просто любопытство :) – zalew

ответ

1

Я проверил тест, с тем же результатом, что и вы. U должен использовать имена полей в нижнем регистре, чтобы он работал. Однако, вам не нужно переписывать sql, можете оставить прописную букву в sql, имея строчный регистр в определении модели, и он будет работать нормально! что странно, потому что имена столбцов PgSql чувствительны к регистру. С другой стороны, Django не позволит вам иметь два поля: один строчный и один прописные буквы с тем же именем (возможно, заблокированные из-за различных db-систем, с которыми работает django), поэтому ... все еще странно :)

Can not если есть какие-либо подробные сведения об этой проблеме. Просто следуйте строчной схеме. Отредактируйте поля модели, чтобы опустить и запустить свой sql.

+0

Ваше понимание - это ответ, зале. Спасибо за помощь! Имена полей в нижнем регистре превратили трюк. Это идеальный вариант, так как большинство номенклатур в любом случае ближе к стандарту в нижнем регистре, и мне лучше как инженер. Я немного поработал и увидел, что MySql не разрешает имена полей, чувствительные к регистру. Возможно, Django хочет ввести строчные буквы для имен полей, но преобразует их в верхний регистр для запросов в любую СУБД. Это странно и неожиданно. Я также вижу, что чувствительность к регистру столбцов является довольно большой проблемой в целом для пользователей MySQL, которые конвертируют в/из других СУБД. –

0

Хм. Выстрел в темноте, может быть, ваш пользовательский SQL выполняется до того, как таблица будет создана с помощью команды syncdb?

+0

В документе Django говорится, что код SQL выполняется сразу после операторов CREATE TABLE. Я склонен думать, что они бы подумали о времени. Спасибо за ваши мысли. –

 Смежные вопросы

  • Нет связанных вопросов^_^