Ну что народ

Кто как аплоады файлов делает в рест апи?

Мультипартом шлёте или отдельный эндпоинт какой-то?

мультипартом на отдельный эндпоинт)

Т.е. энтити только через рилейшены на файлы завязаны получается?

Типо есть какая-то энтити аля MediaFile

И все остальные на неё?

да. в текущем проекте удобнее так

Мультипартом шлёте или отдельный эндпоинт какой-то?

отдельным, на ендпоинте читаю стдин и пишу в файл, стримом, чтоб не жрать память.

Я тут просто нашел два выхода чтобы в обычный рест интегрировать мультипарт

Либо активировать настройку в пхп

Либо использовать https://github.com/notihnio/php-multipart-form-data-parser

Остановился на библиотеке

Добрый день, сериализовал ли кто-нибудь object или массив на пхпшный лад, с выполнением Closure внутри? Нужно сделать serialize() Guzzle/Client с сохранением переменых

ох))

В джсон его засунь

В джсон его засунь

Потом мне все это дело вызвать надо, и в рамках джэйсона, вроде как, переменные среды (или не знаю, как правильно сказать) не учитываются. Мне затем вызвать инстанс этого Guzzle надо будет

Добрый день, сериализовал ли кто-нибудь object или массив на пхпшный лад, с выполнением Closure внутри? Нужно сделать serialize() Guzzle/Client с сохранением переменых

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

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

Ага, тоже к нему в итоге пришел), спасибо

По-моему проще сдедать какой-то ДТО из клиента и его сериализовать

По-моему проще сдедать какой-то ДТО из клиента и его сериализовать

С библиотекой имею дело, она сериализует это дело в кэш от react php, а затем его вызывает инстансы

Client - DTO - Json Json - DTO - Client

Ну можно написать кастомный нормалайзер денормалайзер только смысла в этом нет никакого

Где аффтары шутейки нашли человека по имени "Сережа"?

В нынешний то век

Всем добрый день, прошу не хейтить за глупый вопрос) У меня в базе есть поле типа JSON, туда сохрняется дата, все отлично. Но как мне сделать так, что бы я могу добавить к этому массиву другую дату а не перезаписать эту, то есть если я сейчас выберу еще одну другую дату то он перезапишет эту…

$entity->dayOff[] = '12.12.2022'

$entity->dayOff[] = '12.12.2022'

офигеть, спасибо больше

Котаны, а есть какой-нибудь норм десериайлайзер в дто из ассоциативного массива\жсон? Симфонёвый полная помойка, а жмс тормознутый совсем

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

особо вариантов нет, либо кодген, либо симфони

Я вариантов других не нашел. Симфоневский по красоте всё делает но тяжелый пздц. Пришлось руками перекладывать, т.к. он тяжелый ппц

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

если есть какая-то схема апи, типа сваггера, можно самим дтошки генерить и делать им именованный конструктор ::fromArray(array $data): self {}

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

очень не советую этого делать 🙂

я про вторую часть идеи

Я вариантов других не нашел. Симфоневский по красоте всё делает но тяжелый пздц. Пришлось руками перекладывать, т.к. он тяжелый ппц

Ага, по красоте))) Пишешь: public function __construct( public int $some ) {} Присылаешь json: {some: "asdasd"} и он валится с typeerror, вместо ошибки валидации

ну или тоже самое без промотуед проперти

Там выключается исключение при проверке типа

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

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

симвонёвые констреинты работают после

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

Ну не знаю, могли бы бридж на валидатор добавить

чтоб можно было отловить название поля, ожидаемый тип и отправляемый

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

Особо доставляет такой кейс: public function __construct( public readonly DateTime $date ) {} {"date": "2019-07-07"} // OK {"date": "2019-42-42"} // TypeError: Expected DateTime, but string passed

И выловить и превратить в: field "date" must be correct datetime string - нереально

Я уж не говорю про то, что нормалайзеры глобально конфижатся и ограничить: public DateTime $date, // expected "Y-m-d" public DateTime $datetime, // expected "Y-m-d H:i:s" невозможно никак

А почему не отвалидировать json до того, как начать сериализовать?

Ну и невозможность сделать /** @var array<MessageDTO> */ public array $items тоже удручает

А почему не отвалидировать json до того, как начать сериализовать?

ну так симфони валидатор по ДТО же валидирует))))

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

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

эти невалидные данные могут от юзверей придти

не должно такого быть, если у вас на обоих концах апи (клиент-сервер) описаны контракты этого апи в виде схемы

Послать можно что угодно

А почему не отвалидировать json до того, как начать сериализовать?

https://symfony.com/doc/current/components/serializer.html#collecting-type-errors-while-denormalizing

если какой-то кулхацкер шлёт руками запросы с заведомо битыми данными - ок, можно и упасть с тайп эррором

https://symfony.com/doc/current/components/serializer.html#collecting-type-errors-while-denormalizing

работает ТОЛЬКО если поле не null и только если оно обычное проперти

если как часть конструктора или нуллабл, то отваливается

работает ТОЛЬКО если поле не null и только если оно обычное проперти

а версия сф?

а версия сф?

5.4 но на 6.х такая же фигня

есть ишью на гх?

Только некоторые

работает ТОЛЬКО если поле не null и только если оно обычное проперти

правда? Получается мое гавно еще актуальное🤣 https://github.com/Myaza-Software/Schema-Validator

Вот одно из https://github.com/symfony/symfony/issues/44925

Т.е. это причина, почему нельзя выдрать название поля из partial denormalization ошибки

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

Сейчас и так пришлось обмазаться конвертерами ошибок, вида: MissingConstructorArgumentsException, NotEncodableValueException, PartialDenormalizationException, NotNormalizableValueException, пытаясь их как-то превратить в ValidationFailedException

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

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

если какой-то кулхацкер шлёт руками запросы с заведомо битыми данными - ок, можно и упасть с тайп эррором

Нельзя, т.к. это раскрывает внутрянку

так ему не показывайте тип ошибки

просто "пришли невалидные данные"

Нельзя так

Нужно сказать ещё в каком месте ошибка

что поле Х некорректное, например

у вас публичное апи или для своего фронтенда?

Полупубличное под мобилки и веб.