مرحبًا ، أود أن أخبركم اليوم عن كيفية ترقية مشروع من الإصدار 1.9 إلى 2.0. ما هي الفروق الدقيقة الرئيسية التي يجب مراعاتها وإعادة كتابتها حتى يبدأ المشروع في الإصدار الجديد من Django.
الخطوة الأولى
هذا تحديث لـ Django إلى الإصدار 2.0 ، بالإضافة إلى تحديث جميع الحزم ذات الصلة المستخدمة في المشروع ، أستخدم البيئة الافتراضية و.txt. ثم بالنسبة لي هذه طريقة واحدة ، فقد تكون مختلفة بالنسبة لك.
بعد قيامك بتحديث جميع الحزم ، يجب ألا تبدأ المشروع ، ولن يبدأ على أي حال ، لذا ابدأ فورًا في إصلاح جميع النقاط الرئيسية حتى يبدأ المشروع.
الخطوة الثانية. تحديث جميع عناوين urls.py لمشروعك
في عناوين urls.py الرئيسية الخاصة بك ، والتي تقوم فيها بتضمين عناوين url من تطبيقات أخرى ، نقوم بتوصيل:
من django.urls استيراد re_path ، المسار.
ونقوم بتغيير c url إلى path ، بالإضافة إلى إزالة التعبيرات العادية في هذه الاتصالات.
url(r'^ some/', include('some.urls')),
إذا كنت تستخدم طرق العرض مباشرة من هذا التطبيق ، والذي يتطلب النظامي ، فإننا نستخدم:
re_path(r'^app/$', App.as_view(), name='app')
في تطبيقات المكونات الإضافية (على سبيل المثال ، بعض / urls.py) ، في ملف urls.py ، نستخدم:
re_path(r'^create/$', Create.as_view(), name='create')
إذا كنت تستخدم مساحة الاسم في عناوين URL أثناء التضمين ، فقم بحذفها من هناك ونقلها مباشرة إلى التطبيق المتصل. نذهب إلى urls.py من هذا التطبيق ونكتبه فوق urlpatterns = []
app_name = 'app-application'
يعمل هذا الخط كبديل لمساحة الاسم وهو مصمم لجعل عناوين urls.py الرئيسية أكثر نظافة وقراءة ، بالإضافة إلى تسهيل تغيير الأسماء في مكان واحد.
الخطوة الثالثة
نستخدم البحث طوال المشروع ، اعتمادًا على محرر الكود الذي تستخدمه أثناء التطوير ، يمكن أن تكون مفاتيح اختصار مختلفة ، أعتقد أنك تعرفها ، لذلك لن أتوقف هنا.
نحن نقود في:
is_authenticated()
والتغيير إلى
is_authenticated . الآن هذه ليست طريقة ، بل خاصية. سيؤدي هذا الخطأ إلى استثناء.
مزيد من المشروع الذي نبحث عنه:
from django.core.urlresolvers import reverse
وتغيير إلى:
from django.urls import reverse
الخطوة الرابعة
الآن في جميع النماذج. مفتاح خارجي ، يجب أن يكون هناك وسيطة موضعية إلزامية "on_delete" على سبيل المثال:
on_delete=models.CASCADE on_delete=models.DO_NOTHING on_delete=models.SET_NULL
التالي نقوم به:
python manage.py makemigrations python manage.py migrate
الخطوة الخامسة
إذا حاولت بدء المشروع ، فيجب أن يبدأ بالفعل ، ولكن على الفور سيعطيك خطأ بمجرد أن تذهب إلى 127.0.0.1:8000.
سيكون الخطأ كما يلي:
AttributeError at / 'WSGIRequest' object has no attribute 'user'
يرجع ذلك إلى حقيقة أنك تحتاج إلى إعادة تسمية MIDDLEWARE_CLASSES إلى MIDDLEWARE
بعد ذلك ، ستحصل على الخطأ التالي في وحدة التحكم:
django.core.exceptions.ImproperlyConfigured: WSGI application 'application' could not be loaded; Error importing module: 'application doesn't look like a module pathيحدث هذا الخطأ لأن لديك وسيطة قديمة ، ويجب عليك تحديثها إلى:
'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.middleware.security.SecurityMiddleware'
الخطوة السادسة
إذا كنت تستخدم الوسيطة الخاصة بك في المشروع ، فيجب أن تكون موروثة من MiddlewareMixin ، وليس من الكائن (يمكنك أيضًا استخدام الكائن ، ولكن بعد ذلك تحتاج إلى تسجيل طرق إضافية مطلوبة).
استيراد:
from django.utils.deprecation import MiddlewareMixin
هذا كل شيء! :)
بالطبع ، إذا كان لديك مشروع كبير جدًا وكنت تستخدم عددًا كبيرًا من الحزم ، فستواجه المزيد من المشاكل ، ولكن بالفعل سلسلة من الأخطاء في وحدة التحكم ستساعدك على حلها وبدء المشروع في الوضع المناسب. يصف هذا الدليل الأخطاء الرئيسية وطرق حلها ، والتي تتعلق بجميع المشاريع باستخدام Django 1.9 (بعض النقاط ليست ذات صلة بإصدار Django 1.11) ، وسوف يساعد على نقل المشروع بسرعة إلى Django 2.0 ، بالإضافة إلى تجنب ضياع الوقت غير الضروري للتحليل والبحث حلول للأخطاء الشائعة.