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

Swagger codegen. Генерится api клиент для js, если я правильно понял вопрос

Swagger codegen. Генерится api клиент для js, если я правильно понял вопрос

у меня есть ответ от роута в json формате, хочу его преобразовать в OpenAPI аннотации к роуту

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

у меня есть ответ от роута в json формате, хочу его преобразовать в OpenAPI аннотации к роуту

#[ Route(path: '', name: 'create_payment', methods: Request::METHOD_POST), OA\Post(summary: 'Создание платежа'), OA\RequestBody(content: new Model(type: CreateRequest::class)), OA\Response( response: Response::HTTP_OK, description: 'Ok', content: new Model(type: CreateResponse::class), ), IsGranted("IS_AUTHENTICATED_FULLY"), ]

у меня есть ответ от роута в json формате, хочу его преобразовать в OpenAPI аннотации к роуту

https://symfony.com/bundles/NelmioApiDocBundle/current/index.html

в данном случае у меня форвардинг ответа от внешнего сервиса

Там есть пример

в данном случае у меня форвардинг ответа от внешнего сервиса

ну ответ же все равно в DTO каком-то описан?

dto до чертиков простое getCode, getData , и дату выплёвывает

в каком виде эта дата?

json

от роута к роуту произвольный

по сути форвардинг ответа от внешнего сервиса

#[ Route(path: '', name: 'create_payment', methods: Request::METHOD_POST), OA\Post(summary: 'Создание платежа'), OA\RequestBody(content: new Model(type: CreateRequest::class)), OA\Response( response: Response::HTTP_OK, description: 'Ok', content: new Model(type: CreateResponse::class), ), IsGranted("IS_AUTHENTICATED_FULLY"), ]

ну как ни крути, для сваггера, действительно, нужно будет описывать все поля каждого json. на лету, на сколько я знаю, он не умеет. как будто самый простой вариант - создать для каждого json ответа DTO, и пропихивать его в виде модели в nelmio bundle, как в примере, что я скинул.

ну как ни крути, для сваггера, действительно, нужно будет описывать все поля каждого json. на лету, на сколько я знаю, он не умеет. как будто самый простой вариант - создать для каждого json ответа DTO, и пропихивать его в виде модели в nelmio bundle, как в примере, что я скинул.

пока что это единственный альтернативный вариант, спасибо за помощь

еще один потенциальный вариант: просто скопировать ответ какой-нибудь и в виде example вставить, ни хрена ничего не описывая))) колхозненько, но быстро

как вариант взять и гненерить тем же swagger code generator клиент для php и из него вытянуть модели ответов

но если api изменится, то надо будет это повторить снова

как вариант взять и гненерить тем же swagger code generator клиент для php и из него вытянуть модели ответов

В него json импортировать можно ?

он берет json, в котором все описано (OpenAPI) на remote. по этому json гененит клиент и классы (dto) под определенный язык (по шаблонам, которые можно править самому). в результате у вас получается библиотека-клиент к какому-то api. из нее вы достаете нужные объекты (dto) и возвращаете их в качестве модели ответа.

Сомкнуть ряды!

А чо в доктрине в коллекциях метод findFirst() удаляет найденный элемент?

А чо в доктрине в коллекциях метод findFirst() удаляет найденный элемент?

Вроде не должен

Может он не удаляет элемент, а просто при следующем чтении итератор коллекции начинает идти не с первого элемента

Попробуй сделать rewind коллекции и прочитай заново

у меня при каждом выборе из коллекции пропадает 1 элемент блин... кроме этой хрени ниче нету больше такого )

А как каллбек выглядит?

А как каллбек выглядит?

короче, orphanRemoval в сущности виноват :D пасиб Нельзя его юзать на 1к1

Всем привет! Использую API Platform. Я хочу вынести работу с ApiResource из App\Entity в другое место. Для этого, я создал папку ApiResource, и поместил туда мою сущность A с необходимыми мне полями. То есть, теперь я имею два файла по пути App\ApiResource\A и App\Entity\A. В App\Entity\A у меня определенна сущность со всеми поля с аннотациями ORM\Column... А в App\Api\Resource есть другой класс, который имеет аннотацию ApiResource и со всей конфигурацией, которая относится к API, есть processor, provider. Правильный ли это подход? Какие будут проблемы с таким подходом? Подскажите плиз

Мне кажется с таким подходом легче расширятся. Конечно, больше писанины, но главное это легко расширятся

Но какие будут проблемы, кто пробовал такое?

Всем привет! Использую API Platform. Я хочу вынести работу с ApiResource из App\Entity в другое место. Для этого, я создал папку ApiResource, и поместил туда мою сущность A с необходимыми мне полями. То есть, теперь я имею два файла по пути App\ApiResource\A и App\Entity\A. В App\Entity\A у меня определенна сущность со всеми поля с аннотациями ORM\Column... А в App\Api\Resource есть другой класс, который имеет аннотацию ApiResource и со всей конфигурацией, которая относится к API, есть processor, provider. Правильный ли это подход? Какие будут проблемы с таким подходом? Подскажите плиз

Правильные подходы те - которые вы будете использовать системно.

Можно абстрагировать код так, как вы хотите. Я вообще не использую сущности в модулях. Каждый модуль объявляет свой интерфейс своей сущности и использует его. А так же объявляет интерфейсы сервисов. А всякие доктриновские сущности, репозитории эти интерфейсы реализуют. сегодня доктрина, завтра урина, вообще насрасть. Все эти внешние библиотеки - это грязь

То о чём вы говорите вообще не имеет правильного решения, каждый дрочит как он хочет

Вы можете разбить код на модули, а каждый модуль будет реализовывать контрллеры, сущности, сервисы, репозитории и любую чушь которая вам нужная А можете разбить верхний уровень на контроллеры, сущности итд итп, а внутри бить на модули А можете только сервисы бить на модули, остальное в свалку

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

короче, orphanRemoval в сущности виноват :D пасиб Нельзя его юзать на 1к1

Звучит сильно странно. Скорее всего колбэком что то делал.

Звучит сильно странно. Скорее всего колбэком что то делал.

Не, вот например у тебя есть у юзера аватарка, и он может загрузить несколько штук. Как в телеге. Одна из них главная

Всем привет! Использую API Platform. Я хочу вынести работу с ApiResource из App\Entity в другое место. Для этого, я создал папку ApiResource, и поместил туда мою сущность A с необходимыми мне полями. То есть, теперь я имею два файла по пути App\ApiResource\A и App\Entity\A. В App\Entity\A у меня определенна сущность со всеми поля с аннотациями ORM\Column... А в App\Api\Resource есть другой класс, который имеет аннотацию ApiResource и со всей конфигурацией, которая относится к API, есть processor, provider. Правильный ли это подход? Какие будут проблемы с таким подходом? Подскажите плиз

Звучит интересно, но будет отчётливая проблема с dry. Что то добавлять в двух местах, что то удалять так же. А если платформа где то потребует в будущем жесткую связь с сущностью , придётся все переделывать. Имхо почистить код от атрибутов почти не имеет реального профита, кроме "чистоты". А вот dry и потенциальные риски - есть

выбор главной не запросом в бд делается, а поиском из списка Пример: $newAvatar = $user->getAvatars()->findFirst(...); $user->setAvatar($newAvatart); аватар и юзер 1к1, и если ставишь орфан ремовал то при смене аватарки удаляется старая.

выбор главной не запросом в бд делается, а поиском из списка Пример: $newAvatar = $user->getAvatars()->findFirst(...); $user->setAvatar($newAvatart); аватар и юзер 1к1, и если ставишь орфан ремовал то при смене аватарки удаляется старая.

Ну все верно работает. Так и должно. Это не 1 к 1 влияет

Орфан удаляет сущность при любой смене связи.

хз, я думал так быть не должно )

Он для этого и существует. Это уникальное владение. Т.е. Когда ты его ставишь, то сущностью может владеть только один "родитель". При смене родителя или его занулении сущность удаляется

хз, я думал так быть не должно )

Погугли разницу между орфан, cascade remove

А это. Какие бест практики по юзер сущности? Хранить весь мусор типа пола прямо в нем или one2one делать со всей инфой?

А это. Какие бест практики по юзер сущности? Хранить весь мусор типа пола прямо в нем или one2one делать со всей инфой?

Создать сущность профайл, а юзер толькодля аутентификации, имхо

Вообще обычно абсолютно все равно как ты сделаешь. Шок, но это правда

Через десять лет проект скорее всего перепишут либо забудут

Поэтому пиши как хочешь )

Я видел таблицы по 30 полей. Видел таблицы с одним полем. Вообще без разницы все

Капец ты мрачный

Ну ок храни в отдельной таблице потому что .. потому что так наверное правильно. Почему правильно? Та никто не ответит нормально

Потому что невозможно ответить на такие вопросы однозначно. Если у тебя 90 процентов запросов в системе возвращают эти данные, то лучше в одной таблице, если данные нужны редко, в отдельной

А это. Какие бест практики по юзер сущности? Хранить весь мусор типа пола прямо в нем или one2one делать со всей инфой?

Как угодно можешь делать. Если хранать всё в одной таблице то за один запрос сможешь получать все данные и не надо будет делать по 100500 запросов для получения аватарки, настроек итд итп Как минус - при работе массивом пользователей будет большая нагрузка по памяти и возможно ты бы не хотел запрашивать то, что не используешь

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

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

Потому что невозможно ответить на такие вопросы однозначно. Если у тебя 90 процентов запросов в системе возвращают эти данные, то лучше в одной таблице, если данные нужны редко, в отдельной

Да, тут верно @zim_it а какая ответственность будет возлагаться на user сущность? Что он должен мочь делать?

https://youtu.be/tD5NrevFtbU?si=9N9SeIz4IOOrZPLA

Вот это видео

Я думаю он частично прав, потому что всё-таки если перформанс страдает но например сильно повышается читаемость кода и это важно в данном проекте, то ну почему бы и нет

Да, тут верно @zim_it а какая ответственность будет возлагаться на user сущность? Что он должен мочь делать?

Ну просто как токен. Считай просто идентификатор

Ну ок храни в отдельной таблице потому что .. потому что так наверное правильно. Почему правильно? Та никто не ответит нормально

Ну есть несколько причин, но можно найти и обратные: За: 1) Строковая БД, т.е. даже читая колонки, считываются строки и это прямо влияет на производительность (но на сколько?) 2) Контексты профиля и аутентификации разные. Сущности меньше, меньше каплинг, проще писать тесты(банально меньше фикстуры заполнять). Разрабы меньше пересекаются, меньше конфликтов. SRP из SOLID 3) Разбиение на таблицы (1-1) уменьшает объем сущностей участвующих в транзакциях, а значит уменьшает шансы конфликтов и локов. Хотя это наверное мало касается именно этой задачи. Против (но это скорее в общем а не про юзеров): 1) Если все же придется выводить вместе - это лишний join. 2) Приходится как то поддерживать атомарность и консистентность. Ну тип если все делить на контексты, значит надо сохранять эти сущности отдельно, как то обернуть в транзакцию или же иначе все это организовать. Ну тип кейс когда данные авторизации создались, а профайл выбил ошибку и нет. Что делать? Раньше все изи - в пользователя напихали и всё. Опять лишняя сложность. Этот пункт больше всего напрягает, для себя пока не понял как это делать адекватно, легко и без просадок по длине транзакции

А это. Какие бест практики по юзер сущности? Хранить весь мусор типа пола прямо в нем или one2one делать со всей инфой?

Нету их. Юзер сущность это комплексная штука. Можно смело выделять несколько контекстов при работе с ней, из общего между ними будет тока ид. Например зайди в гугл, там есть секьюрити, профиль, настройки и прочее. Это все можно поделить на части и оно будет работать отдельно друг от друга.

Можно начать например с embedded а потом если что отоеяакторить в отдельную таблицу если будет вопрос произвольности

Не знаю сам так не делал )

Суть в том что что такое юзер вообще. Юзер это какой-то уникальный идентификатор в системе наделённый иногда определенными правами. Все остальное это какой-то обвес вокруг этого идентификатора

Суть в том что что такое юзер вообще. Юзер это какой-то уникальный идентификатор в системе наделённый иногда определенными правами. Все остальное это какой-то обвес вокруг этого идентификатора

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

Юзер может иметь несколько кредов. Это тоже Ван ту мени по идее. Например логин через имейл или oauth или брелок с токеном

Так что как-то да получается что юзер это какой-то голый идентификатор с минимумом полей типо активный, дата создания и т.л.

Если это какой-то специальный тип юзера где есть обязательное поле часто делают через inheritance mapping в орм

https://youtu.be/xjTYg4jc37g?si=bO2ALfFBOhgO2q68

Кстати кому интересно, можете глянуть. Лайк если не жалко )

Кстати кому интересно, можете глянуть. Лайк если не жалко )

Если вратце, go на равне с пых + свул по rps? Оо

Да и памяти меньше )

Я сам удивился. Но это свуль

Симфу я даже тестить не буду ну разве что в режиме RR

Я там уже много всего потестил, раст пока на первом месте

Удивил ещё nodejs, который обошел го

Удивил ещё nodejs, который обошел го

Чет тогда не понятно что за хайп с го, если его та же нода обгоняет