2016-08-15 2 views
-1

У меня есть сайт с Django 1.9, управляемый на Ubuntu, и я очень часто сталкиваюсь с какой-то странной проблемой, когда некоторые ошибки исчезают, когда я запускаю клон проекта локально с моего ПК используя 127.0.0.1:8000 url. Локализация ошибки в таких случаях чрезвычайно трудоемка, и мне интересно, какие лучшие методы отладки крупномасштабного проекта, особенно когда веб-сайт уже частично используется. Чтобы быть как можно более конкретными, я предоставляю пошаговое описание того, что пойдет не так.Сайт Django дает ошибку, которая не появляется при запуске локально

Шаг 1. набираю некоторый URL, скажем, 10.8.0.1:8000/show_students/

Шаг 2. Выполните некоторые действия на странице, например, сохранить профиль студента. Операция не заканчивается успешно, что приводит к ошибке.

Шаг 3. Я скопирую каталог проекта, расположенный на удаленном сервере, в локальный каталог на моем ПК и попытаюсь запустить CLONE. Я вижу, что ошибка не имеет места.

Реальный пример,

task_email_recipients = TaskEmailRecipients.objects.get(task_type = 
task_instance.type, legal_entity_own = legal_entity_own_instance) 

Эта линия бросает исключение, сказав, что LegalEntityOwn has no field named (да, я ничего не пропустить. Это пустая строка после того, как «поле с именем») Если я запускаю тот же вид из 127.0.0.1 ошибка исчезает. Какими должны быть мои действия? BTW, я использую Eclipse, если это имеет значение. И у меня MS Windows 10 на моем локальном ПК.

Подводя итог, моя цель состоит в том, чтобы отладить запуск проекта от 10.8.0.1

UPDATE для - комментарий Пола Becotte в Я всегда игнорировал это предупреждение, но при выполнении проекта, он выдает предупреждение

У вас есть непримененные миграции; ваше приложение может не работать должным образом, пока не будут применены . Запустите «python manage.py migrate», чтобы применить их.

+2

Вы ... A. Использование источника управления? B. Использование миграции для управления схемой вашей базы данных? C. Развертывание приложения в автоматическом режиме? Такие проблемы обычно возникают из-за беспорядочного развертывания на развернутом сервере, а затем забывают, что вы это сделали, и лучший контроль над тем, что фактически работает в обоих местах, обычно устраняет эти проблемы. –

+0

Пол, см. Обновленный вопрос. Не могли бы вы прояснить оба пункта (A. и B.)? –

ответ

1

Итак, позвольте мне объяснить несколько концепций.

A. Source Control (Git) позволяет отслеживать все изменения в исходном коде. Это очень важно, так что вы можете быть уверены, что используете ту же версию своего кода на своей машине разработки, что и ваш развернутый сервер, не пытаясь сделать что-то вроде копирования файлов туда и обратно. Команда вроде git status может показать вам, если вы что-то изменили и, возможно, дадите советы о том, что отличается между двумя средами. Если вы не используете git, вы должны немедленно начать!

B. Миграции как источник управления для схемы вашей базы данных. База данных SQL, такая как Mysql или Postgres, имеет фиксированную схему: у вас есть ЭТО много таблиц, с именами THESE, а таблица A имеет три столбца, одна из которых называется Name и одна с именем ID и т. Д. Миграции предназначены для того, чтобы дать вам представление о том, что такое схема. Вместо входа в базу данных и запуская CREATE TABLE A ..., вы создаете файл миграции, который содержит необходимые команды, а затем маркирует базу данных номером версии. Затем вы запускаете эти командные файлы, чтобы, если базы данных находятся на одной и той же версии, вы знаете, что они имеют одинаковую структуру (что позволяет вам сопоставить вашу локальную базу данных с вашим развернутым). Django имеет полезную систему миграции, встроенную в ... manage.py migrate - это команда для применения всех файлов миграции к текущей базе данных.Если вы получаете сообщение об ошибке, которое вы указали, практически нет возможности, что ваше приложение будет работать должным образом, потому что ваша схема базы данных где-то не синхронизирована с вашими файлами модели. Основываясь на вашем очень ограниченном описании, вы добавили поле в модель, которая теперь существует в вашей локальной базе данных, но не существует в вашей производственной базе данных.

C. Я упомянул сценарий развертывания - это единственная команда, которую вы можете запустить, чтобы запустить ваш код на удаленном сервере, чтобы вы были уверены, что это происходит одинаково каждый раз. В этом случае это может быть что-то вроде ...

ssh production 
git pull 
python manage.py migrate 
uwsgi 

Создайте скрипт вроде этого, так что вы знаете, что происходит, и вы можете исключить из случайно пропуская шаги как вектор ошибки.

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