Не, в твоём кейсе я даже не знаю что выбрать, согласен

Переменную и exec ?

Переменную и exec ?

ну как бы да )

Добро пожаловать, @themostannoyingperson! Не забудь ознакомиться с правилами чата: https://t.me/ru_python/802295!

а там короче был эксперимент

имхо лучше все это переписать на анзибль и не париться

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

ребят, вопрос по django rest framework. Есть модели на подобии этих - https://dpaste.de/w5Ue#L Как при сериализации вывести их на одном "уровне"? Например: { "id": 1, "name": "Client 1", "phone": "112233445566", "email": "asd@gmail.com" }

разделить модель БД и DRF и делать ручками из одной другую

или как там DRF работает

Ручками то сделаю, просто время займет. Думал, может у DRF готовы свои методы...

ну хз может кто другой знает

Ручками то сделаю, просто время займет. Думал, может у DRF готовы свои методы...

Первое что приходит в голову - запилить в базе view с результатом JOIN-а этих двух таблиц. А в джанге замапить эту view на "модельку". Но наверное это уже будет не совсем ванильная Djanga - тут надо будет ручками в базе создавать всякие VIEW-шечки.

чет выглядит сложно

Ручками то сделаю, просто время займет. Думал, может у DRF готовы свои методы...

https://stackoverflow.com/questions/21381700/django-rest-framework-how-do-you-flatten-nested-data

не то?

чет выглядит сложно

Ну всё зависит от ситуации - если ему по производительности подойдёт "ручное" склеивание данных в питоне, то наверное это будет проще в плане "всё в одном месте".

https://stackoverflow.com/questions/21381700/django-rest-framework-how-do-you-flatten-nested-data

Вот поэтому я и не люблю api-фреймворки зависящие от схемы данных/ORM

любой нестандартный кейс выливается в какие-то костыли

которые потом сложно поддерживать

Вообще схема БД должна быть независима от схемы API

Хотя в какой-то момент жизни проги может и совпадать

Вообще схема БД должна быть независима от схемы API

ну вот DRF же мапит апи прям на модели

изменение схемы данных без изменения апи в DRF будет довольно больно

Да Джанго в целом - набор антипаттернов

drf хорош только для примитивного crud'а

ну вот DRF же мапит апи прям на модели

может мапить, может не мапить правда возможность мапить это его главное достоинство

может мапить, может не мапить правда возможность мапить это его главное достоинство

ну да, его можно использовать вообще без orm, но кому он тогда нужен будет?

ну да, его можно использовать вообще без orm, но кому он тогда нужен будет?

ну прям сейчас мне в текущем проекте, общий карскас для построения API там совсем не плох, если уже и так используется django

ну прям сейчас мне в текущем проекте, общий карскас для построения API там совсем не плох, если уже и так используется django

в смысле без использования orm?

в смысле без использования orm?

ормка используется по самому минимуму, только там где через неё удобнее и не критична скорость, но никакой автоматической генерации апишки, всё руками и местами свой конструктор запросов.

изменение схемы данных без изменения апи в DRF будет довольно больно

да вообще не особо, для таких вещей же Serializer'ы и придуманы. изменил схему данных - чуть переписал Serializer

ормка используется по самому минимуму, только там где через неё удобнее и не критична скорость, но никакой автоматической генерации апишки, всё руками и местами свой конструктор запросов.

В такой схеме в drf'е придется оперировать dict'ами. Если конечно не имплементировать какой-нибудь dataclass serializer

да вообще не особо, для таких вещей же Serializer'ы и придуманы. изменил схему данных - чуть переписал Serializer

К сожалению это не всегда так. Проблема использования serializer'ов поверх моделей еще и в том, что это подталкивает к использованию бизнес-логики внутри сериалайзера

а еще drf serializer очень медленный

К сожалению это не всегда так. Проблема использования serializer'ов поверх моделей еще и в том, что это подталкивает к использованию бизнес-логики внутри сериалайзера

Я так и делаю, но выглядит это зашкварно, да. А куда лучше логику выносить? В сервисы?

Я так и делаю, но выглядит это зашкварно, да. А куда лучше логику выносить? В сервисы?

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

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

Пора переходить на фласк и пытаться сделать удобно ?

Хотя в итоге может получиться своя джанга, что тоже хз

seralizer - это же view, аналог темплейта, не?

seralizer - это же view, аналог темплейта, не?

в целом, так и есть. И в этом его проблема, кмк

Добро пожаловать, @Empire_Oaxaca! Не забудь ознакомиться с правилами чата: https://t.me/ru_python/802295!

А кто-то работал с файлами с расширением .types, я просто вообще не могу найти такое расшерение

а что там?

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

ткни file

что он скажет?

а что там?

Я должен создать конфигурационный файле mime.types

ха

а ты сможешь?

А кто-то работал с файлами с расширением .types, я просто вообще не могу найти такое расшерение

Плохо искал, первая ссылка на первой странице гугла

https://filext.com/file-extension/TYPES

это не .types файл, а конкретный mime.types

Я должен создать конфигурационный файле mime.types

nginx? ОС какая?

аппле 2 это не прошлый век?

https://filext.com/file-extension/TYPES

Ага не увидел

nginx? ОС какая?

ubuntu

это не .types файл, а конкретный mime.types

А оно разве чем-то отличается?

тем что это один единственный файл такой

тем что это один единственный файл такой

Понял

https://wiki.debian.org/MIME/etc/mime.types - это про него

ERROR: S client not available

как постаивть какой-нибудь дефолтный щас надо погуглить

вообще должен быть дефолтный /etc/nginx/mime.types говорят

блин, забыл

вообще должен быть дефолтный /etc/nginx/mime.types говорят

Ага есть такое только у меня он /etc/mime.types

Ага есть такое только у меня он /etc/mime.types

Ну норм. А в чем вопрос тогда?

дикий оффтопик как бы

Ну норм. А в чем вопрос тогда?

Та я не могу найти как с ним взаимодействовать, типо я ему кидаю файл и он мне возвращает его тип и подтип

Добро пожаловать, @Karinish! Не забудь ознакомиться с правилами чата: https://t.me/ru_python/802295!

Добро пожаловать, Николай! Не забудь ознакомиться с правилами чата: https://t.me/ru_python/802295!

Та я не могу найти как с ним взаимодействовать, типо я ему кидаю файл и он мне возвращает его тип и подтип

Никак, это тупо файл со списком. Тебе из питона надо или как?

Никак, это тупо файл со списком. Тебе из питона надо или как?

ага

meme.types

ага

import magic попробуй

import magic попробуй

Да уже нашел спасибо

do you know da wae

в целом, так и есть. И в этом его проблема, кмк

хм, это с какой точки зрения, они аналоги?

Руководитель отдела OpenStack #работа #офис #selectel #openstack #teamlead #python #IaaS #VPC В компании Selectel открыта вакансия Руководитель отдела OpenStack: https://selectel.ru/careers/all/vacancy/#29979235 На этой позиции вы будете руководить развитием сервисов и инфраструктуры продукта Виртуальное приватное облако. В вашей команде будет работать 10 разработчиков и системных администраторов. Мы ищем человека с опытом разработки и поддержки проектов в роли тимлида, с твёрдым характером, добрым сердцем и желанием изменить мир к лучшему. Наши ожидания: владение навыками высокоуровневого проектирования, построения схем взаимодействия сервисов, опыт работы с облачными продуктами (OpenStack, VMware, Azure, AWS), с python, git, curl и sql, опыт разработки или системного администрирования, участие в opensource проектах. Офис: Санкт-Петербург, улица Цветочная д.21 Гибкое начало рабочего дня (до 12:00) ЗП: от 200 000 (готовы обсуждать) Присылайте резюме на hr@selectel.ru, готова ответить на вопросы @Karinish

хм, это с какой точки зрения, они аналоги?

Ну с такой, например, что ModelSerializer делает запросы в БД

Ну с такой, например, что ModelSerializer делает запросы в БД

и поэтому сериалайзеры аналоги шаблонов? О_о если мы говорим про джанговские шаблоны, это пиздец какие разные вещи

вот сериалайзеры DRF вполне себе аналог форм в джанго

или может я контекст не уловил

и поэтому сериалайзеры аналоги шаблонов? О_о если мы говорим про джанговские шаблоны, это пиздец какие разные вещи

оу, я че-то неправильно прочитал сообщение @Tishka17. Не шаблонов конечно, а аналог view в терминах джанги

оу, я че-то неправильно прочитал сообщение @Tishka17. Не шаблонов конечно, а аналог view в терминах джанги

Хз как там в джанге вьюхи, они же должны быть максимально тупые и просто маппить данные и вызывать шаблон, да?

Хз как там в джанге вьюхи, они же должны быть максимально тупые и просто маппить данные и вызывать шаблон, да?

ну не обязательно шаблон, view же может что угодно возвращать, json, например

ну да

но сериалайзер в drf не просто сериализует/десериализует данные, но делает запросы в базу