Парни! А что для главной страницы вставлять?

  <li><a href="{% url 'index' %}" {% if "

ЗДЕСЬ

" in request.path %}class="disabled"{% endif %}>Главная</a></li>

Я сделал

 <li><a href="{% url 'index' %}" {% if request.path == '/' %}class="disabled"{% endif %}>Главная</a></li>

Но тогда вопрос. Как с помощью регулярки там сделать "/ [и больше ничего]" а так же "/pagename [и всё что угодно справа]"

Функция get_or_create  сразу заносит данные в базу, или нужно дополнительно использовать функцию save ?

По названию можно понять, что она делает)

Ты ведь в результате получаешь кортеж из двух сущностей. Инстанс записи в базе и статус

Уже понял, спасибо

Привет! Скажем, есть таблица Объекты, на которую ссылается таблица Фото через foreign key. И еще эта же таблица Объекты имеет связь многие-ко-многим с таблицей Метки.
Как в рест правильно решать задачу вставки новых записей:
1) Написать отдельные вью с отдельными эндпойнтами для создания новых записей по каждой таблице.
2) Создать вложенные сериализаторы и все обработать в одной вью.
Я пыталась пойти по второму пути, но у меня не получилось реализовать это. Если второй вариант и есть правильный, то подскажите ссылку, где подобные примеры (со внешними ключами) можно разобрать?

Дрф применяю

ну первый вроде как правильнее
второй проще

в доках это примерно так описано
https://www.django-rest-framework.org/api-guide/relations/#writable-nested-serializers

но там это в сериализаторе делается

Второй не показался мне проще, я мозг сломала, как его реализовать)
Если у клиента все должно отправиться с одной страницы, то он, при первом подходе, получается, должен отправить несколько запросов, верно? Не противоречит ли это принципу рест "один запрос на одно действие"?

Спасибо за ссылку, буду разбирать

там скорее один едпоинт отвечает за одну сущность

первый вариант проще для бека
сложнее для фронта

те нужно создать одну запись
от которой зависят другие
получить ответ
потом отсылать по одной на саздание связаных сущностей

как правило это усложняет фронт, замедляет работу
и есть риск что клиент оборвет действием цепочку запросов

Большое-пребольшое спасибо за объяснения! Прочитаю материал по ссылке, может, остальные вопросы отпадут.

у второго тоже есть свои подводные камни
проблема с валидацией
не всегда понятно на какой сущности запнулась валидация

если делать логику во въюхе
то может быть такое что главная сущность создалась (отработал serializer.save())

при обработке зависимых запинается валидация
на фронт уходит исключение
и он пытается создать по новой а там уже есть запись

Это же транзакцией вроде решается. Разве нет?