Ну вот поэтому я и ворвался, так как это была провокационная фраза, а я падок на провокации.

Это ваши личные проблемы, что вы можете что то считать или не считать провокацией.

Все хватит

Не конструктивно

Не конструктивно

Эх, меч конструктивности затачивается в уличных полемиках.

@dexplon извиняюсь если где-то перешёл на личности или просто перегнул. Это просто спор о тестах, ничего более.

@dexplon извиняюсь если где-то перешёл на личности или просто перегнул. Это просто спор о тестах, ничего более.

Ок, взаимно. Мир

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

Через подзапрос собрать idшники и дальше сджоинить основные записи по этому подзапросу а не по связной таблицы

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

Если выбрать то вроде никак, ее же нет в сущности. Ну если говорить про сущности. Если нужно просто условие, то можно джоин но именно по fcqn сущности, а не по связи. т.е. не ->join('e.rlation','r') а ->join(Relation::class, 'r', 'WITH' (не помню или ON), 'r.id = e.relation_id')

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

Тебе нужно выбрать записи или сущности?

сущности A у которых A.entityB === null

сущности A у которых A.entityB === null

Ну если связь есть, то должно работать null вроде...

SELECT A LEFT JOIN pivot_table as pt WHERE pt.b_id is null ? так чтоль?

Короче смысл в том что при left join там где отсутствует связь в пивот таблице на месте b_id будет null и вот тут мы их и ловим

НО я хз как в квери билдере избавится от дублей A

$this->createQueryBuilder('t1') ->join('t1.table2', 't2') ->where('t2 = null') ->getQuery() ->getResult();

типа такого надо

НО я хз как в квери билдере избавится от дублей A

Если QB от ORM то сама все разрулит, а вот уже если нативно, то да, надо самому мержить

$this->createQueryBuilder('t1') ->join('t1.table2', 't2') ->where('t2 = null') ->getQuery() ->getResult();

leftJoin

Ну и is null скорее всего

Если QB от ORM то сама все разрулит, а вот уже если нативно, то да, надо самому мержить

да, просто если сущностей B в несколько раз больше чем A то там от бд будет большой IO Нужно в рамках запроса это решить

ну да ессно is null

leftJoin

сработало! спасибо

да, просто если сущностей B в несколько раз больше чем A то там от бд будет большой IO Нужно в рамках запроса это решить

Ну если сгруппировать даже, объем же вроде не изменится.

Или тупо из-за кол-ва строк будет выше IO?

Просто если группируем - то это оверхэд по конкатинации, так как делиметеры

Ну я так, не шарю, чисто рассуждаю

А вообще если вам грозят сложные запросы и вы знаете как сделать это чистым sql но не хотите мучится с qb то вот чит который я открыл для себя https://habr.com/ru/articles/496166/

Короче ResultSetMappingBuilder

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

А вообще если вам грозят сложные запросы и вы знаете как сделать это чистым sql но не хотите мучится с qb то вот чит который я открыл для себя https://habr.com/ru/articles/496166/

Кстати к прошлому спору про эту фичу, вот эту статью я вроде когда то и читал, и там как раз каждое поле в примере мапится

Видимо у меня и осталось в памяти что гемор

Не рокет сайнс конечно, соглашусь

Видимо как раз билдер это решает, в нем уже как то поменьше кода

А вообще если вам грозят сложные запросы и вы знаете как сделать это чистым sql но не хотите мучится с qb то вот чит который я открыл для себя https://habr.com/ru/articles/496166/

спасибо, закинул в список для изучения

Ну я так, не шарю, чисто рассуждаю

там да, я тоже хз как доктрина поведёт себя если в неё кучу одинаковых записей пихать. Ни будет ли она десериализовывать их каждый раз. Короче да, сначала наверное лучше забрать DISTINCT или GROUP BY id шники а уже по ним вытащить записи. У меня на проекте просто могут в сущностях и json лежать и вот при таких LEFT JOIN реально может быть большой IO Девопсы наказывают за это

там да, я тоже хз как доктрина поведёт себя если в неё кучу одинаковых записей пихать. Ни будет ли она десериализовывать их каждый раз. Короче да, сначала наверное лучше забрать DISTINCT или GROUP BY id шники а уже по ним вытащить записи. У меня на проекте просто могут в сущностях и json лежать и вот при таких LEFT JOIN реально может быть большой IO Девопсы наказывают за это

А ну т.е. в 2 запроса. Я просто думал про select GROUP_CONCAT(JSON_OBJECT) left join group by подобное

Т.е. когда мы на уровне sql в одном запросе схлопавыаем группу и строим json или строку с множеством записей, чтобы на уровне пыхи не мержить дубли

спасибо, закинул в список для изучения

Вот тут более строгая дока https://www.doctrine-project.org/projects/doctrine-orm/en/3.1/reference/native-sql.html#resultsetmappingbuilder

Вот тут более строгая дока https://www.doctrine-project.org/projects/doctrine-orm/en/3.1/reference/native-sql.html#resultsetmappingbuilder

спасибо, тоже в список для изучения

Короче ладно, я сейчас попробовал расписать все ЗА и ПРОТИВ при написании теста на вот такую логику. Это просто мысли, а не моё мнение которому я следую: { $entity= $this->repository->get() $this->calculator->action($entity) $this->em->flush() } 1) Юнит тест НУЖЕН, если вы работаете по методологии которая говорит что "Юнит/Строчка кода не должна быть написана, пока на неё нет отдельного падающего теста". 2) Юнит тест НУЖЕН, так как СЕЙЧАС нет комбинаторики, но ПОТОМ она может появится и хорошо, если бы на это был бы падающий тест. Если упал юнит тест, но не упал функциональный - это должен быть триггер к изменению функционального (приёмочного) теста. (тест как сигнализация к изменениям) 3) Юнит тест НЕ НУЖЕН так как то, что он тестирует является частью другого теста (redundant test). 4) Юнит тест НЕ НУЖЕН так как в тестируемом коде нет никакой сложной логики. 5) Юнит тест НЕ НУЖЕН так как есть мнение что если "Если тест сложный, значит тестируемый код плохо написан". Возможно имеет место и обратная логика "Если тест СЛИШКОМ простой, то от класса/метода нужно избавиться".

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

Поэтому нужно следовать рамкам здравого смысла

Не стоит слепо доказывать кому-то что только так и не иначе

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

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

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

Не везде конечно это так, есть сферы где нужно долго и без багов, зависит короче от бизнесов

Не везде конечно это так, есть сферы где нужно долго и без багов, зависит короче от бизнесов

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

нормально делай - нормально будет https://www.youtube.com/watch?v=RGXNgXj9t4M

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

главное только на собесе такое не говорить ))

Как только ты вынесешь логику в сервисы, то увидишь что все можно тестировать юнит тестами и это очень удобно и главное быстро и не требует кернела

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

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

всем привет а symfony messenger умеет в rpc rabbitmq?

всем привет а symfony messenger умеет в rpc rabbitmq?

конечно

привет! подскажите как в апи платформе красиво сообщать юзеру о том что сущность нельзя удалить из-за форейн кей?

Просто упади с 500

А вообще у тебя есть 3 варианта 1) упасть с 500, так как это явно похоже на попытку сделать то, что системой не расчитывалось 2) если расчитывалось то или каскадное удаление 3) или soft delete

привет! подскажите как в апи платформе красиво сообщать юзеру о том что сущность нельзя удалить из-за форейн кей?

Перед удалением можно проверить есть ли связи заполненные через дата персистеры

Просто упади с 500

оно само падает с 500, фронт не доволен

оно само падает с 500, фронт не доволен

Ну тогда пусть с 400

Перед удалением можно проверить есть ли связи заполненные через дата персистеры

во, уже там ковыряюсь, только стейт процессор, спасибо!

Ну тогда пусть с 400

как это пусть?

Это сокращённое от «пускай»

Это сокращённое от «пускай»

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

Фронт является источником контрактов. Как он скажет так и делай

ты хотел наверное сказать что знаешь где перехватить доктриновский эксепшон?

Твоя задача нормально закодировать бизнес логику

Их задача дать тебе контракт

Фронт является источником контрактов. Как он скажет так и делай

та я разве против, сижу, делаю

Твоя задача нормально закодировать бизнес логику

спасибо, кеп

привет! подскажите как в апи платформе красиво сообщать юзеру о том что сущность нельзя удалить из-за форейн кей?

Ну просто ты думаешь как красиво сообщить. Пусть тебе фронт скажет Это может быть 1) http код 2) специфичный json объект 3) некий message 4) некий код ошибки

Их задача дать тебе контракт

ваще не согласен тут если фронтам даывать контракты делать то там быстро появится ok=true и error=false

Ну просто ты думаешь как красиво сообщить. Пусть тебе фронт скажет Это может быть 1) http код 2) специфичный json объект 3) некий message 4) некий код ошибки

Там скорее вопрос как это сделать по технике апи платформ. Там свои ньюансы

проверено много раз

Ну просто ты думаешь как красиво сообщить. Пусть тебе фронт скажет Это может быть 1) http код 2) специфичный json объект 3) некий message 4) некий код ошибки

бро, я про апи платформу а не про мир во всём мире

Там скорее вопрос как это сделать по технике апи платформ. Там свои ньюансы

Ааа, ну так бы и спросил Ну я бы всё равно бы листенер исключений впендюрил

Ааа, ну так бы и спросил Ну я бы всё равно бы листенер исключений впендюрил

Ну так и спросили в первом сообщении :)

Ну так и спросили в первом сообщении :)

Было не очевидо. Я бы листенер ставил, самый надёжный способ