Question

我有一个我在过去几年里建立的项目，它是在Django 1.4中开始的。运行此项目的服务器需要更换，因此我正在迁移到新服务器。

我考虑借此机会将项目升级到Django 1.7。我一直在查看笔记，我知道我会就url标签以及其他一些事情做些工作。但是，看起来项目的主要结构已经发生了变化。在我的项目中，settings.py，static文件夹和项目范围urls.py文件/文件夹都在项目的根目录中。但是，在1.7（可能是之前的几个版本）中，似乎这些文件/文件夹被移动到主项目中的app文件夹。

例如，我的1.4项目的项目结构为：

project folder:
    - urls.py # all other app urls.py files are included in this main urls file
    - static # all static files for the whole project reside here
    - settings.py # project settings
    ./app:
        - urls.py #app specific urls

但是现在，似乎默认的项目结构已经改为：

project folder:
    - # there's nothing here other than the "manage" script
    ./project:
        - # an 'app' with the same name as the project now holds project wide files
        - urls.py # project wide urls file?
        - settings.py # project wide settings? within this app folder?
        - static # project wide static files to be held here?

那么，鉴于新的项目结构，我是否能够在1.7中运行我的项目？

Answer 1

您可以在Django中拥有您想要的任何项目结构。因此，除了任何其他升级问题，您将能够运行您的项目。目前最好的项目结构示例之一是PyDanny的Django Cookiecutter。

除了抽象的用户类，身份验证和迁移（以及与之一起的syncdb / schemamigration之类的命令）之外，没有任何东西可以阻止升级。有些东西已被折旧，但它们记录良好且易于修复。在每个版本中，他们都确保升级路径和向后兼容性是明确的并且尽可能好。

我建议遵循1.5,1.6和1.7的最佳做法，这些做法改变了社区编写Django应用程序的方式。我最喜欢的资源是Two Scoops of Django。 PyDanny是作者之一。有两个版本，分别为1.5和1.6，每个版本都讨论了之前版本与新功能如何改变你应该编写Django应用程序的方式之间的主要差异。通过阅读两者，您可以清楚地了解如何将应用程序从1.4升级到1.5到1.6。除此之外，每个版本的发行说明和django-cookiecutter都是很好的地方，可以看到最新变化以及新的最佳实践。

Answer 2

我想清楚这是上面harshil提供的link上找到的答案的提炼版本。我在这里添加它以防万一URL在将来中断，因为它帮助了我。

向SECRET_KEY

SETTINGS.PY

在Django 1.5中更改，Django现在要求每个项目都有一个SECRET_KEY。

1.7应用程序和应用程序注册表的概念：

这是1.7中引入的新概念，其中Django维护了已安装应用程序的注册表，因此可以非常轻松地管理和内省所有应用程序。我喜欢这个功能的最好的部分是，它使管理子应用程序变得非常容易，并且在每个应用程序准备就绪时运行初始化代码。

您可以在此处了解详情：https://docs.djangoproject.com/en/1.7/ref/applications/

升级DJANGO模板URL标签以使用DJANGO 1.5中引入的新语法：

如果您已经在使用Django的{% load url from future %}，则可以跳过此步骤，但如果您不是，则必须立即将url tags from {% url view_name args %}更改为{% url 'view_name' args %}。

有一个非常棒的sed命令可用于将所有url标记转换为新格式。您可以从模板目录

sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g" *

或者为了以递归方式运行它，您可以运行以下命令：

find . -type f -print0 | xargs -0 sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g"

来自Enrico，可以在stack here上发布此快捷方式。

APP LABELS

从Django 1.4迁移时，我遇到了新的django迁移（这是下一个主题）在识别给定模型所属的“app”时遇到问题的问题。根据经验，我只需将app_label添加到所有模型Meta类中，并将其设置为包（文件夹）名称。

MIGRATIONS

使用Django 1.7，您不再需要南方，因为迁移现在是内置的。从south迁移到django迁移的最佳方法是从迁移文件夹中删除所有迁移文件（将__init__.py留在其中）。

运行以下命令以生成所有新迁移：

python manage.py makemigrations

然后进行迁移（如果django发现该表已经存在，那么它将不会运行这些迁移）

python manage.py migrate

URLS.PY

您的所有urls.py

from django.conf.urls.defaults import patterns, include, url

您需要将其替换为： from django.conf.urls import patterns, include, url

的HttpResponse

如果有任何代码手动设置HttpResponse的mimetype，则需要将其更改为content_type。

HttpResponse({"message": "hello world!"}, mimetype="application/json")变为HttpResponse({"message": "hello world!"}, content_type="application/json")

GET_QUERY_SET

get_query_set方法已被弃用，优先于get_queryset。因此，如果您先前覆盖了get_query_set方法，则需要更改它。

CACHING

如果您使用johnny-cache之类的ORM缓存，则需要杀死它，自行滚动或升级到django-cachalot之类的内容。

插件：

请记住升级所有要求和插件。许多较旧的插件可能与Django 1.7不兼容。

升级至Celery＆gt; = 3.1.16

Answer 3

从1.4 http://labs.seedinvest.com/backend/upgrading-from-django-1-4-to-django-1-7/

升级时，请注意以下事项

Answer 4

这篇文章建议最好的方法，一次只做一个版本步骤：

本节将明确指出您一次只能升级一个版本。您不应该直接从1.4升级到1.7。相反，首先从1.4跳转到1.5，然后转到1.6，依此类推。这符合采取小步骤的想法。

请参阅：

http://andrewsforge.com/article/upgrading-django-to-17/part-4-upgrade-strategies/

但是，它可能取决于项目在重构到新版本时“暂停”的时间可能意味着新功能的进展等等必须“暂停”。我想一下子就这么做，这是一个很大的进步，所以一次做很多工作，但是将它分成小步（逐个版本）意味着更短的音轨，但整个音轨可能会更长。

从Django 1.4升级到Django 1.7 - 它会起作用吗？

4 个答案: