Звучит логично, только отловить такое сложно, если там правда виснит процесс. У меня было отдаленное напоминающая ситуация, но без очередей, просто в одном месте в коде подвисал процесс и отапливался и ни какой инфы, это то ещё веселье. В случае с очередями хорошо бы выставлять максимальное время выполнения задач для очереди, пускай падает по превышению таймаута на задачу, а не только на кол-во задач в очереди.
Максим Федоров, так и сделал. Просто думал может есть решение о котором мне не известно. В yii2 у меня тоже валидации не в модели, а в сторонних формах. Спасибо.
Максим Федоров, Данное решение позиционируется как для консольной команды, но опять же я по "правильному подходу" должен буду иметь объект с правилами валидации для консоли и для веб запросов
Максим Федоров, ага, вот только что если у вас изменились правила валидации, по всему проекту надо будет менять эти правила, хотя я например обернул это дело в свой объект. А как другие люди это делают ? Таскают копипасту с правилами ?
Представьте что вам нужно вызвать консольную команду и там создать 3 разных сущности , как валидировать их данные , например на фронте у нас там была своя валидация в контроллере, тут ее теперь тоже дублировать т.е. тот же Request использовать или набор правил . Можно даже представить что Вам нужно отвалидирлвать данные для 3х сущностей а потом сохранить их например если они все валидность
Decadal: Никита: Павел Волынцев: подробное объяснение привёл в моём последнем ответе к данному топику, буду признателен если вы ознакомитесь, чтобы не прыгать нам всем по комментариям
Никита: ожидаю чтобы пришли результаты по А, в котором условия соответсовали для элементов B(left join) для type = 0 и type = 1 т.е. по поиску по обоим объектам принадлежащим одному А
Никита: SELECT `A`.* FROM `A`
LEFT JOIN `B` ON `A`.`id` = `B`.`bid_id`
WHERE (B.price_unit >=10 AND type=0) AND (B.price_unit >=100 AND type=1)
GROUP BY `id`
Получается один из объектов с типом 0 другой с типом 1, как обротиться с условием к обоим не используя подзапрос?
Да оно так и есть с SQL есть проблемы.
Так и есть на данный момент. В одной таблице оба объекта (Таблица B) они различаются переменной type но нельзя одним запросом обратиться сразу к 2м объектам необходим подзапрос. Т.к. поиск и так заморочен, множеством дополнительных полей и joinпо ним, то и ещё подзапрос осложняет весь поиск.
Павел Волынцев: Как считаете может тогда разнести их по разным таблицам, облегчит логику самих данных и поиск будет легче как минимум без подзапроса к одному из объектов потом к другому.
Павел Волынцев: Да к сожалению mysql не понимаем что это логически разные объекты, в представлении базы это просто один объект на который ссылаются два другие. А так да, структура sql такая как Ваша.
Никита: Проблема в том, что надо искать как раз по двум объектам. Они отличаются типами у одного тип 1 у другого 2 и в одном запросе нельзя обратиться сначала к одному и через AND к другому, т.к. они будут противоречить.
Да неплохой вариант. Можно уточнить понятие транзитивности? И будет ли данное решение влиять на производительность, т.к. дополнительный left join через таблицу?
