так для энтити тоже не срабатывает

Как цветовая называется?

Aura Dracula Spirit

а в коде(контроллере) дополнительно валидацию вызываешь?

а в коде(контроллере) дополнительно валидацию вызываешь?

Ничего больше не делаю - у меня ApiPlatform

а в коде(контроллере) дополнительно валидацию вызываешь?

О, я вспомнил почему не работало у меня. У меня цены записываются вместе с товаром. Надо было в свойсво товара добавить атрибут:

validationContext еще наверно может влиять, если задан где-то.

И да, сильно сомневаюсь, что с DTO это будет работать. DTO это не про данные, которые должны быть уникальны, на этом слое ничего про данные неизвестно, и не должно быть известно, так что по идее кроме как на слой ORM это накидывать бесполезно, но я не проверял.

И да, сильно сомневаюсь, что с DTO это будет работать. DTO это не про данные, которые должны быть уникальны, на этом слое ничего про данные неизвестно, и не должно быть известно, так что по идее кроме как на слой ORM это накидывать бесполезно, но я не проверял.

не я хочу в энтити сделать, ту затею я оставил)

привет! подскажите пож это сильно плохо добавить public/bundles/apiplatform/ в гит?

привет! подскажите пож это сильно плохо добавить public/bundles/apiplatform/ в гит?

Я видел так делают

Но обычно так не нужно делать

Я видел так делают

спасибо

да надо в контейнер скопировать а её нету

Билд пайплайн нужен нормальный

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

Куча файлов измененных каждый раз

Билд пайплайн нужен нормальный

да у меня вроде нормальный :)

стащил репу, копирую в контейнер nginx

Ну сделай ассетс инсталл перед этим

не понял это ж надо где-то сделать не тащить же мне в контейнер nginx все зависимости симфы только чтобы этот ассет сбилдить симфой

или я не понял

не понял это ж надо где-то сделать не тащить же мне в контейнер nginx все зависимости симфы только чтобы этот ассет сбилдить симфой

Multistage build

Где то ж бек билдитсЯ

билдится ну типа я сбилдил бек, скопировал наружу эту папочку как-то из контейнера?

склонил репу, вызвал асетс инстал, скопировал все файлы в конейнер

у тебя что-ли код проекта маунтится?

у тебя что-ли код проекта маунтится?

нет, копируется

склонил репу, вызвал асетс инстал, скопировал все файлы в конейнер

не понял где я вызвал ассетс инсталл, на хосте?

Уже подсказали же

COPY --from ...

Почитай про мультистейдж билды

COPY --from ...

во, всё понял, спасибо!

Есть один больой запрос, который собирается из нескольких селектов. Я решил вынести каждый запрос в свой класс. Собрать и пройтись по всем классам-запросам, чтобы склеить это все в один. Вопрос такой, норм ли такое делать через tagged iterator? У классов-запросов нет зависимостей, вроде в контейнер их не особо хочется пихать

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

Просто он сам может быть зависимостью, это нормально

Просто он сам может быть зависимостью, это нормально

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

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

Иногда подходит просто описать сервис в ямле и явно ему аргументы передать

Но это статический конфиг

Возможно тебе подойдёт один класс который принимает SQL строку

А дальше ты в ямле создаёшь сервисы на основе этого класса передавая ему аргумент строку запроса

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

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

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

Ну и самый гибкий вариант это кастомный конфиг и extension который этот конфиг обрабатывает и что-то делает с контейнером

В сервисе примерно такой код. Вот и весь сервис. Цель просто собрать пройтись и собрать один запрос, поэтому как рабочий вариант думал tagged iterator использовать class TotalSumQuery { public function get(): string { return <<<SQL ... SQL } }

Ну ты можешь принять в конструкторе запрос например

И обойтись одним классом

Вынести в ямл это все

Тем более там тоже есть мультистрочные скаляры

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

В сервисе примерно такой код. Вот и весь сервис. Цель просто собрать пройтись и собрать один запрос, поэтому как рабочий вариант думал tagged iterator использовать class TotalSumQuery { public function get(): string { return <<<SQL ... SQL } }

Сделать можно, нужно ли - вопрос. Тут конечно от задачи зависит, но мне кажется там где собирается запрос,горадо приятнее понимать что там будет. Все же вы собираете не абстракцию, а конкретную модель . Т.е. даже какое нить $query.= Main::getQuery() $query.= SubMain::getQuery() Да и вообще в чем проблема забубенить через методы а не через классы. Будет в итоге понятнее чем $foreach($iterator as $queryFactory){ $query.= $queryFactory->getQuery(); } execute($query); // и на этом этапе не понятно что там

С итератором работают все же с абстракцией, когда не важно что там внутри. Слабо понимаю, как может быть не важно содержимое sql

С итератором работают все же с абстракцией, когда не важно что там внутри. Слабо понимаю, как может быть не важно содержимое sql

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

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

Это логика понятна, не понятно что даст полезного итератор в этом случае. Будет ли это полезно. Да какой то OCP но он вам нужен в этом месте? не будет ли он конфликтовать с KISS и мешать пониманию происходящего

Это логика понятна, не понятно что даст полезного итератор в этом случае. Будет ли это полезно. Да какой то OCP но он вам нужен в этом месте? не будет ли он конфликтовать с KISS и мешать пониманию происходящего

Если без итератора, то имеется ввиду вызывать явно каждый класс?

Если без итератора, то имеется ввиду вызывать явно каждый класс?

Ну да, или метод. Просто не понятно что решается таким абстрактным подходом

$query.= $this->getUserQuery(): $query.= $this->getOderQuery(): Я понимаю что тут строится и главное могу быстро пронавигироваться

Ну да, или метод. Просто не понятно что решается таким абстрактным подходом

Пройтись по всему списку запросов и собрать итоговый

Пройтись по всему списку запросов и собрать итоговый

То что вы хотите технически понятно. Не понятно что оно решает в вашем флоу

В целом согласен, что возможно явно лучше это указать

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

Прежде всего исходите от того, что вы пытаетесь решить и чем это поможет кому то

Например у вас может в одном запросе появиться какое то условие. Все вам надо менять весь контракт всех классов, так как у вас интерфейс, а могло бы быть просто $query.= $this->getUserQuery($userId): $query.= $this->getOderQuery():

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

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

Новый заспрой можно добавить хоть лапшой (один большой огромной запорс, без выделения подзапросов вообще). Всегда лишь вопрос что решает то или иное решение

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

Всегда можно скопировать весь запрос и отдебажить в БД

А не бегать по классам и собирать кусочки в один текст

Всегда можно скопировать весь запрос и отдебажить в БД

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

Нужно решать сложности и делать сложное проще, а не просто архиткетурить ради архитектуры

Квери билдеры нынче не в почете... Бида.

А почему ?

Сужу по последнему вопросу 🤷

просто недавно видео видел от создателя cycleorm

он как раз говорил что они выбрали query билдер подход, а не DQL

а почему я не понял -)

он как раз говорил что они выбрали query билдер подход, а не DQL

Потому что dql это костыль

а почему ?

мне dql тоже не очень нравится