Как проверить related_name

Шаг первый — находим в коде модель данных с related_name. Для примера возьмём код онлайн-библиотеки:

class Book(models.Model):
    author = models.ForeignKey(
        User,
        verbose_name='автор',
        related_name='authors'
    )

У нас есть книги и их авторы. Поле related_name позволяет развернуть это отношение и для каждого автора получить список его книг.

Теперь открываем Django shell и пишем запрос с related_name. Выберем любого пользователя из БД и узнаем какие книги он написал:

$ python manage.py shell
>>> from users.models import User
>>> user = User.objects.first()
>>> user.authors.all()

Внимательно перечитываем свой код и видим: хотели книги — books, а получили неких авторов authors. Что за дичь здесь происходит ?!

Исправляем неудачное название related_name на логичное и понятное:

user.author_books.all()

Осторожнее с пользователями!

В примере выше вместо author_books можно написать books. Так получится короче и смысл не потеряется. Так может показаться на первый взгляд, но это не так. Очень часто в модели данных содержится сразу несколько ссылок на учётки пользователей. У книги помимо авторов могут быть рецензенты, читатели, фоловеры и много кого ещё. Всё это ссылки на пользователей и у каждой связи есть свой собственный related_name. Если назвать related_name без уточнений как books, то в связях легко будет запутаться, не ясно о чём речь в запросе об авторстве или о лайках.

Если в модели данных одна связь с пользователями, то это ещё не значит, что в будущем их не станет больше. Функционал сайта постоянно расширяется и лишь одно остаётся в мире неизменным — “требования меняются всегда!”