Подписчики и друзья в приложении Django. Путь непознаного...
В целях личного развития не так давно я решил скопировать Вконтакте с почти всем его функционалом. Естественно что решил всё сделать на Django. На данныймомент всё движется нормально, всё согласно моему тз.И вот собственно я столкнулся с небольшой проблеммой. Я не могу придумать как сформировать модель. То ли мозг закипел, то ли сам загнал себя в тупик .
Есть правда несколько простых набросков:
Первый
class Frends(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) frend_user = models.ForeignKey(User, on_delete=models.CASCADE, related_name="user_frend") def __str__(self): return '%s' %s(user.username)
Тут вроде как всё замечательно выходит, но есть но. При каждом добавлении пользователя в друзья будет создаваться запись в бд а точнее две записи. И если при добавлении нескольких пользователей это нормально. То если их будет очень много то это не очень уже и удобно.
Второй вариант предполагает использование полей типа ManyToManyField. Что то типа вот этого:
class Frend(models.Model): user = models.ForeignKey(User, on_delete=models.CASCADE) frend_user = models.ManyToManyField('self', blank=True, related_name='user_frend') def __str__(self): return '%s' %s(self.user.username)
Конечно можно сделать поле user не ForeignKey а OneToOneField но речь как то не об этом.
Сегодня половина ночи ушла на подбор правильного для меня варианта действий. В принципе в первом варианте легче сделать всякие там подтверждения и остальное на основе флагов. Во втором немного извратившись это тоже можно реализовать. В общем мозг кипит от выбора структуры самой модели что просто отказывается соображать напрочь. Естественно что спустя время ответ сам прийдёт мне в голову. Но на данный момент нужно реализовать именно эту модель и соответственно двигаться далее согласно своему тз.
По этому прошу вашей помощи и объяснений как же более правильно и лучше это реализовать. Буду очень благодарен за оказанную помощь.
P.S.
По итогу решилось что добавлять множество моделей расширяющей модель пользователя не совсем лучший случай. И всё таки как я не хотел переопределять модель пользователя мне это прийдётся всё таки сдклать. Ибо я подумал что не хорошо будет иметь множество моделей ведущих к пользователю, таких как "профиль, контакты, списки заблокированных и так далее". Пытаясь реализовать всё по разным моделям я не учёл тот факт что это не совсем удобно при проверках доступа и определённых действиях. К тому же оно порождает несколько лишних запросов в базу, чего мне бы не хотелось.
Бошльшая часть всех проверок будет нужна постоянной по этому не виже смысла выбирать дополнительно таблицы и заморачиваться с select_related and prefetch_related. По этому я просто добавлю дополнительные поля в переопределённую таблицу и оставлю первый способ реализации добавления подписчиков и друзей.
Хотя кому я всё это пишу то. По ходу себе)))
We recommend hosting TIMEWEB
Stable hosting, on which the social network EVILEG is located. For projects on Django we recommend VDS hosting.Do you like it? Share on social networks!
- Akiv Doros
- Nov. 12, 2024, 1:58 a.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:50points,
- Rating points-4
- molni99
- Oct. 26, 2024, 11:37 a.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:80points,
- Rating points4
- molni99
- Oct. 26, 2024, 11:29 a.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:20points,
- Rating points-10
Начинание хорошее, но лучше не ломайте себе голову в пустую, а используйте эту батарейку для Джанго: django-friendship . Там есть весь необходимый функционал для реализации друзей и подписчиков.
Перед тем как лечь спать я тоже думал что нужно найти батарейку. Однако нагородил огород кода и изобрёл 5 колёсный велосипед. Пошёл записал, проверил. Вроде всё работает но вот велосипед ездит на одном колесе, 4 лишние.
Спасибо я посмотрю в сторону данного дополнения.