Comments 12
@sync_to_async
def get_zodiac_data(zodiac_name):
return ZodiacSign.objects.get(zodiac_en=zodiac_name)а почему не сразу так?
async def get_zodiac_data(zodiac_name):
return await ZodiacSign.objects.aget(zodiac_en=zodiac_name)
А насколько вообще легально валидно хранить svg в БД?)
Ну если сам добавляешь то все ок. Если кто-то другой лучше так не делать)
Есть такая рекомендация, не хранить файлы в БД. Но, никто не отменял логику. Если у вас внутренняя система, которой пользуются 100 пользователей, это ОК хранить файлы в БД, чем разворачивать S3 хранилище.
Если не ошибаюсь, первая версия S3 хранилища Яндекса была реализовано поверх Postgres.
Так это не файлы, а простой HTML-код. Понятное дело, что в боевом проекте это были бы ссылки на SVG, но в целом, какая разница хранить HTML-текст (описание для блока) и в виде HTML-мелкие иконки? Да и база данных тут SQLite) Думаю что для такого проекта точно пойдет)
Я понимаю, что можно так сделать и тренеровочного проекта почему бы и нет. Но по логике это статик файл, а значит и в БД ему не место. Хотелось бы узнать насколько вообще распространена такая практика в проде.)
А в целом, статья мне понравилась. Хотелось бы ещё узнать побольше о паттернах, которые часто используются в Джанго. А так же о работе с файлами.
лучшее, что я читал написанное именно в django стилистике - Django Design Patterns and Best Practices: Ravindran, Arun. Популярная же Two scoops намного менее Django-way книжка. Мне даже с автором удалось пообщаться лично в этом году, но это не делает ее лучше.
SVG это статик файл, пока ты его не меняешь динамически. Но как только ты сохранишь SVG как шаблон(template) с разметкой, куда ты вставляешь динамические данные и, вуаля, уже другая задача. Правда шаблоны тоже стоит хранить статикой. :)
Поскольку SVG это векторный формат, то я храню данные для объектов (class Flowable) которые рендерю через reportlab в SVG.
Со стат файлами надо работать через веб сервер. Да и хранить поближе к клиенту на CDN. Этого в статье нет. Но это стоит знать и использовать.
А по поводу практик - в проде чего только не бывает. Например код python хранят в базе и запускают по запросу через eval/exec. Или в Yaml только настройки, а потом стартуют автогенерацию кода согласно настройкам. Страшные вещи...
Странно, что в статье про Django 5 очень поверхностно используется само Django. Вероятно в этом причина непопулярности и предыдущих статей.
Что автору можно улучшить, чтобы он сам смог понять, оценить и полюбить философию этого фреймворка.
Про objects.aget уже написали. Стоит научиться пользоваться. doc
Так же полезно почитать про фикстуры вместо создания самопальной функции заполнения базы данными. doc
Стоит так же научиться запускать функции проекта через менеджмент-команды, а не через shell. doc
Стоит все же научиться использовать async GCBV вместо FBV. doc
Учимся всегда включать объявление doctype в начало HTML. Doc, например, тут.
Для асинхронного проекта с forloop в шаблоне идем читать про рендер шаблона по частям через
StreamingHttpResponse. docВсе что стоит в href заворачиваем фильтром |slugify, просто потому что. doc
Вероятно, что через некоторое время захочется выбросить gunicorn и начать запускать через uvicorn. Предлагаю сделать это с самого начала. doc
Ну и напоследок, @yakvenalex, стоит научиться уважать читателей и размещать ссылки на репозиторий напрямую, а не через телеграм.
Странно, что в статье про Django 5 очень поверхностно используется само Django. Вероятно в этом причина непопулярности и предыдущих статей.
@danilovmy причина непопулярности прошлых публикаций в том, что очень поверхностно используется само Django? У меня это вообще первая статья по данному фреймворку.
Или вы о том, что я всегда поверхностно разбор делаю? Если так, то тоже не понятно. У меня есть циклы по 10-13 статей, в которых я рассматриваю просто конкретные фреймворки (aiogram и fastapi например). Кроме того, есть чисто практические статьи. Которые, обычно, подразумевают изучение не практических. Да и вопрос популярности и нет относителен. Есть статьи, которые набирают более 10к просмотров, есть и те которые за 25к и за 100к.
По поводу улучшений. Тут согласен, и в планах было это все раскрыть подробнее в следующих публикациях, видать, не судьба) Логика в том, чтоб изначально показать, как писать быстро и просто, а далее уже углубляться. За ссылки на доки спасибо.
К примеру, зачем новичку, который только знакомится с фреймворком, сразу погружаться в такие темы, как «рендер по частям», фикстуры и прочее. Вам самим не кажется, что это вот так, на старте, сможет просто отвернуть от фреймворка?
В статье был сделан акцент, что целевая аудитория текста — новички. Хотел показать, что можно писать без особого погружения в тему и делать это быстро, френдли)
По поводу ссылки в канале. Не считаю, что размещение ссылки на свой репозиторий в своем канале — это неуважение к читателям. Считаю, что я, как автор этого кода, имею право размещать его там, где посчитаю нужным. Я же не на ваш, например, репозиторий у себя в канале ссылку размещаю)
И хочу отметить, что канал бесплатный и не обязательно даже подписываться на него, чтоб забрать ссылку)
В статье был сделан акцент, что целевая аудитория текста — новички. Хотел показать, что можно писать без особого погружения в тему и делать это быстро, френдли)
Чем плохо с упрощениями - есть 100500 статей "для новичков" и практически ничего нет на тему "пишем код для продакшена". Уж лучше сразу писать "как надо", а если хочется упростить, то хотя бы оставлять ссылки на материал/документацию как люди пишут для продакшена.
Django 5: асинхронный бекенд и эффектный фронтенд с минимальными затратами времени