【问题标题】:Django syncdb on SQL initial data using PostgreSQL yields "column ... does not exist"使用 PostgreSQL 的 SQL 初始数据上的 Django syncdb 产生“列...不存在”
【发布时间】:2010-11-29 19:35:26
【问题描述】:

平台:Python 2.5、Django 开发根、PostgreSQL 8.4、Windows Vista Ultimate SP2。 过程:Django 文档,1.0 版,link text,第 34.2 节,提供初始 SQL 数据。

代码:

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 删除了以前版本的坏表,控制台命令“python manage.py syncdb”会产生以下错误:

创建表 application1_aisc_customary 为 application1.aisc_customary 模型安装自定义 SQL 无法为 application1.aisc_customary 模型安装自定义 SQL:关系“application1_aisc_customary”的列“mty​​pe”不存在 第 1 行:插入到 application1_aisc_customary(MTYPE、EDI_STD_NOME...

克拉指向 MTYPE 的 M。尽管有错误,但列(大写)MTYPE 确实存在,如使用 pgAdmin III 所见。请注意,Django admin 报告了该表,但它没有记录。

我已经为 SQL 尝试了 unicode 和 ANSI 编码,从模型属性中删除了 editable=False,并为除模型属性之外的所有内容都使用了小写名称。也许我错过了一些准备性 SQL 语句。我要出击了。我将非常感谢有启发性的回应。提前感谢您的帮助。

09/21/09:郑重声明,zalew 的回答是正确的。需要小写的字段名称。我还必须将一个字段名称 id(内径)更改为 i_d 以纠正与主键的明显冲突。我将 od 更改为 o_d 以匹配。问题解决了。

【问题讨论】:

  • 它并没有解决你的问题,但是为什么你加载 sql 而不是一个fixture 来存储初始数据呢?
  • 为什么不呢?也就是说,如果它可以工作!将原始 .csv 数据库重铸为 SQL 很容易,所有名称都在左侧,所有值都在右侧。我在 Notepad++ 中使用宏来做到这一点。另一方面,JSON 或 YAML 将需要一个简短的 Python 脚本。不过,如果我无法弄清楚 SQL 的问题是什么,我就会这样做。我不知道这两种方法有什么很大的优势,因为我建议在 INSERT INTO 命令之外通过这个工具不使用自定义 SQL。可能 SQL 会加载得更快,但这是一次性的,不是考虑因素。
  • 当然,我只是出于好奇:)

标签: sql django django-syncdb


【解决方案1】:

我做了一个测试,结果和你一样。 U 必须使用小写的字段名称才能正常工作。但是,您不必重写 sql,可以在 sql 中保留大写字母,在模型定义中使用小写字母就可以了!这很奇怪,因为 PgSql 列名区分大小写。另一方面,Django 不会让你有两个字段 - 一个小写和一个同名的大写(可能由于 django 使用的各种数据库系统而被阻止),所以......仍然很奇怪 :)

但无法找到有关此问题的任何背景详细信息。只需遵循小写约定即可。编辑模型字段以降低并运行您的 sql。

【讨论】:

  • 你的洞察力就是答案,zalew。谢谢您的帮助!小写的字段名称变成了窍门。这是理想的,因为无论如何大多数命名法都更接近小写的标准,并且对我作为工程师来说看起来更好。我做了更多搜索,发现 MySql 不允许区分大小写的字段名称。也许 Django 想要小写的字段名称,但将它们转换为大写以查询任何 DBMS。这是奇特的和出乎意料的。我还看到,对于正在与其他 DBMS 进行转换的 MySQL 用户而言,列名区分大小写通常是一个相当大的问题。
【解决方案2】:

嗯。在黑暗中拍摄,也许您的自定义 SQL 正在通过 syncdb 命令创建表之前执行?

【讨论】:

  • Django 文档说 SQL 代码是在 CREATE TABLE 语句之后执行的。我倾向于认为他们会考虑时间问题。不过,感谢您的想法。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-12-06
  • 1970-01-01
  • 2015-11-09
  • 1970-01-01
  • 2018-03-12
相关资源
最近更新 更多