Django特质

缺少复合主键。 bug 已经开放了8年。对于依赖于很多多对多表的应用程序来说，不必要有一个不必要的自动主键，并且使用unique_together属性来解决这个问题。 参考： - comments.gmane/gmanep.python.django.devel/37301 - 如何删除Django中自动生成的ManyToMany表中的冗余ID字段 - code.djangoproject/wiki/MultipleColumnPrimaryKeys#Multi-ColumnPrimaryKeysupport - code.djangoproject/ticket/373

Lack of composite primary keys. The bug has been open for 8 years. Isn't this bad for an app that relies on a lot of many-to-many tables to have a unnecessary auto primary key and work around with unique_together attribute. Reference: - comments.gmane/gmanep.python.django.devel/37301- How to remove redundant ID field in auto-generated ManyToMany table in Django?- code.djangoproject/wiki/MultipleColumnPrimaryKeys#Multi-ColumnPrimaryKeysupport - code.djangoproject/ticket/373

简单的例子就是在SQL模式中表示默认值。我知道他们为什么不会修复它的原因，但它使生活更加困难。 参考： - https：//code.djangoproject。 com / ticket / 470

Something simple like having a default value being expressed in SQL schema. I know the reason why they won't fix it but it makes life harder. Reference: - code.djangoproject/ticket/470

无法声明固定字段

参考： - code.djangoproject/ticket/9349

下载（从上述错误报告引用）：在我的特定应用程序中，从Django自动生成的varchar字段字段将数据库的大小从550GB降低到300GB。有很多情况下真正需要存储的固定长度字符数据。

Downside (quoted from the above bug report) : In my particular application, changing from Django-autogenerated varchar fields to char fields dropped the size of the database from 550GB to 300GB. There are many cases when there really is fixed-length character data that needs stored.

主键不能被无符号（错误报告已经很久很久了）。这不难实现。它使可用ID加倍。

Primary Key can't be unsigned (bug report has been going back & forth for a long time). This isn't hard to implement. It doubles the available IDs.

参考： - https：/ /code.djangoproject/ticket/56

正如我所说，这只是一个开始。我遇到了一些缺点，让我觉得，如果Django忽略了这样的基本的东西，是正确的框架来继续吗？我想问社区，Django充满了需要黑客的其他简单的东西的问题，还是只是一些例外？

As I said, this is just a start. I've encountered some shortcomings that gives me a feel that if Django has ignored such basic stuff, is it the right framework to go ahead with? I would like to ask the community that is Django full of problems that require hacks for otherwise straightforward stuff or are these just a few exceptions?

我正在考虑尝试金字塔/派生框架。任何帮助/建议将不胜感激。

I'm thinking of trying out Pyramid/Pylons Framework. Any help/advice would be appreciated.

更新：再添加2个

老实说，如果这些东西是阻止你的，不要使用Django。我是Django非常强大的支持者，但如果你觉得不满足你的需要，你应该去别的东西。

Honestly, if those things are blockers for you, don't use Django. I am a very strong proponent of Django, but if you feel it doesn't meet your needs, you should go with something else.

我必须说，那些是奇怪的事情要固定下来我不能想象为什么一个中间的M2M表上的一个额外的主键字段是一个问题。 （请注意，复合字段（包括PK）已经成为今年夏季代码项目的主题，并且已经准备好合并 - 请参阅 groups.google/forum/#!topic/django-developers/CD7OrkJ63zc ）

I must say though that those are odd things to fixate on. I can't imagine why an extra primary key field on an intermediate M2M table would be a problem at all. (Note, however, that composite fields - including PKs - has been the subject of a Summer of Code project this year, and looks ready to merge - see groups.google/forum/#!topic/django-developers/CD7OrkJ63zc)

再次，为什么在SQL级别缺乏默认值使生活变得更难是很难理解的：如果您通过Django的ORM进行所有操作，那么应用默认值就没有区别;正如阿德里安所说的那样，在SQL中做这个事情，实际上可以通过使可调用的默认值不可能实现减少当前的功能。

And again, why the lack of defaults at an SQL level "makes life harder" is hard to understand: if you're doing everything through Django's ORM, where the default is applied makes no difference; plus, as Adrian said on that ticket, doing it in SQL would actually reduce the current functionality by making things like callable defaults impossible.

另外你应该反思为什么你'让这些相对微不足道的细节掩盖了Django给你的巨大好处：表现力的ORM，模板语言，蓬勃发展的社区，大量的第三方应用程序...但是，即使这样说，你再次可以选择其他的东西如果真的不适合你。

Also you should reflect on why you're letting these relatively trivial details overshadow the great benefits that Django gives you: expressive ORM, template language, thriving community, huge numbers of third-party apps... But, even that said, once again you're free to choose something else if it really doesn't work for you.