Как назначить пользователя на модель в моей базе данных
from django.db import models
from datetime import datetime
from django.contrib.auth import get_user_model
User = get_user_model()
class Blog(models.Model):
user = models.ForeignKey(User, on_delete=models.CASCADE)
headline = models.CharField(max_length=250)
content = models.CharField(max_length=2050)
time_created = models.DateTimeField(default=datetime.now, blank=True)
def __str__(self):
return self.user.username
каждый раз, когда я мигрирую это
"(venv) PS C:\Users\user\Desktop\APPS\web_app_project> python manage.py makemigrations"
Я всегда получаю это сообщение:
"Невозможно добавить не нулевое поле 'user' в блог без указания значения по умолчанию. Это происходит потому, что базе данных нужно что-то заполнить в существующих строках. Пожалуйста, выберите исправление:
- Предоставить одноразовое значение по умолчанию сейчас (будет установлено для всех существующих строк с нулевым значением для этого столбца)
- Выйти и вручную определить значение по умолчанию в models.py.
Выберите опцию: "
".Как мне поступить
Вы, вероятно, могли бы обойтись добавлением пользователя вручную, используя python shell- python manage.py shell затем импортировать необходимые модели.
Читать больше из похожего вопроса здесь:
Как использовать оболочку python shell
Можно добавить UUID в модель пользователя и сделать поля, требующие пользователя в других моделях, CharField, хранящим UUID пользователя.
Поскольку вы добавили ненулевое поле user в Blog, Django должен добавить пользователя во все экземпляры блогов в базе данных, как новые, так и существующие. Если вы создали экземпляр блога в базе данных, что Django должен сделать с его новой колонкой пользователя? Именно об этом он вас и спрашивает.
Только если в базе данных нет данных или вы полностью согласны с потерей данных, вы можете перевести свое приложение в нулевое состояние с помощью python manage.py migrate <your app name> zero (Вы можете захотеть выполнить обратную миграцию, помимо zero. Вы можете прочитать больше об обратной миграции ). Это фактически отменит все ваши миграции для этого приложения. Затем вы можете удалить существующие миграции для этого приложения и снова запустить makemigrations. Django больше не будет жаловаться на ненулевое поле user, так как это приводит к миграции, которая создает таблицу Blog с полем пользователя, вместо миграции, которая пытается добавить поле user к существующей таблице Blog. И снова, не делайте этого, если вы не боитесь потерять данные. Это следует никогда не делать, если ваше приложение уже работает в производстве, но это нормально, если вы никогда не развертывали приложение и у вас нет "реальных" данных, и вы все еще находитесь на начальной стадии разработки. Кроме того, убедитесь, что у вас есть резервная копия удаленных миграций на случай, если вам понадобится добавить их обратно.
Как уже предлагали другие, вы можете создать модель пользователя по умолчанию, которая будет использоваться как одноразовая модель по умолчанию для добавления user в Blogs. Например (в оболочке Django)
from django.contrib.auth import get_user_model
User = get_user_model()
user = User(username='default_blog_user')
user.set_unusable_password() # Nobody should be able to log in as this user
user.save()
print(user.id) # keep this ID
Затем, при миграции, вы можете использовать то значение user.id, которое было в качестве одноразового значения по умолчанию. Но это опять же предполагает, что вы не развертывали систему на производстве, так как одноразовое значение по умолчанию и идентификаторы в разработке и производстве могут не совпадать.
Если вы уже развернули систему в продакшн, я думаю, единственное, что вы можете сделать, это сделать поле пользователя нулевым для целей миграции, но утверждать, что оно не нулевое в вашей логике программирования. Например, путем добавления валидатора к полю.
Примечание: вместо того, чтобы выполнять get_user_model в вашем модуле models, вы должны сделать следующее:
from django.conf import settings
class Blog(models.Model):
user = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# etc.
Когда вы определяете внешний ключ или отношения "многие ко многим" к модели пользователя, вы должны указать пользовательскую модель с помощью параметра AUTH_USER_MODEL.