mitaichik

В дополнение к предыдущим ответам: нельзя забывать и про настройку сервера - что там у вас под капотом - nginx + php-fpm такую задрежку не даст, а вот apache + php_mod - вполне может.

Довольно опрометчиво считать время выполнения только по запросам к БД - php тоже может съедать не мало, не самый быстрый язык.

Особенно в контектсе профайлинга, дебаггинга - Yii при этом пишет собирает и пишет огромное кол-во инфы на диск, если вы YII_DEBUG отключите возможно все и залетает.

Тормозить может и из-за XDebug если он у вас по умолчанию включен.

Ну и ненужно забывать что скорости отдачи - понятие не постоянное. И если на вашей виртуалочке на dev-машине она 0.3, то на нормальном сервере она вполне может быть и 0.1

Посмотрите вот на эту строку : вы, скорее всего, сравниваете строки, а не даты.
$model->srok<date('Y-m-d')
Так же вы не проверяете $reminder->save() - он может не сохраниться.

Сделайте explain, посмотрите что там происходит.

Автоматом такое не может быть. Вы сами где-то задаете method = test. Ищите ошибку в своем коде. Возможно вы устанавливаете параметры с помощью DI?

Странно конечно... У вас сколько строк в юзерах? Базу больше никто не грузит? Движок случаем не MyIasm? id - примари кей для Юзера? Что EXPLAIN показывает? Может диск битый?

Максим Тимофеев парвильно сказал, но иногда, в какой-нить сложной бизнес-логике, реально бывает необходимость получить id еще не сохраненной сущьности. Для решения этой проблемы нужно отказаться от автоинкрементов в таблицах и получать id у какого-нить счетчика, например, redis incr.

Все описанно в документации https://github.com/yiisoft/yii2/blob/master/docs/g...
Так же можете посмотреть как это реализованно в самом Yii

Попробуйте аннотацию mixin
https://youtrack.jetbrains.com/issue/WI-1730

Репозиторий (хранилище) должен содержать логику сохранения/поиска/восстановления объектов. Валидация - это как бы не его задача. В энтерпрайз фреймворках для этого создаются отдельные сущности.

Что касается Yii - то в нем ActiveRecord несет несколько обязанностий: это и сущность с бизнес-логикой, и валидатор, и репозиторий, и жизненный цикл и т.п. Вы вынесли логику хранения в репозиторий, хорошо. Теперь вам нужно выносить логику валидации куда-то.

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

Я это все к тому, что если вы все это хотите выносить, и идти против архитектуры фреймворка (что не так-то просто), то зачем использовать Yii? Может лучше сразу взять фреймворк который более подходит к вашей архитектуре?

Так вы сами подпишитесь на свою рассылку, и узнаете что и как там приходит.
У нас в компании есть ящик куда шлется копия всех отправленных писем. Да, там сотни тысяч писем, зато все знаем. Плюс к этому все письма шлются через очередь, остаются записи в БД.

Для локального тестирования мы используем MailCatcher. Можете его развернуть, тестировать, смотреть что приходит.

Думается что стандартным средством такого не сделаешь, нужно писать свой UrlRule где зашивать эту логику. Вот документация : https://github.com/yiisoft/yii2/blob/master/docs/g...

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

Здесь нужно пользоваться ActiveDataProvider. Он соединяет в себе и пагинацию, и выборку данных, и сортировку.

И да, count($home->news) - вы понимаете насколько это неоптимальная конструкция? В общем, юзайте ActiveDataProvider - он все сделает правильно.

По хорошему, в модели должна быть только логика сущности. Валидация - в какой-то мере логика сущности. Паттерн ActiveRecord добавляет туда еще и работу с БД. Это удобно для относительно простых проектов, но если у вас сложная работа с БД то класс модели распухнет. Поэтому имеет смысл выносить логику БД из класса модели в соответствующие объекты. Например, репозитории. Еще отличным примером выноса логики работы с БД - это создание для класса своего ActiveQuery с своими скоупами. Бизнес\Операционную логику - в соответствующие сервисы. Логику валидации - в свои валидаторы. Ну и т.п.

У hasMany действительно два аргумента, по ссылке что-то неправильное указанно (скорее всего документация взята с каких-то альфа версий чтоли, когда фреймворк еще в разработке был). Вот где читать надо https://github.com/yiisoft/yii2/tree/master/docs/g...

Вот про релейшены https://github.com/yiisoft/yii2/blob/master/docs/g...

Лично я с сфинксом не работал, ничего не могу сказать, но на первый взгляд у вас все правильно. Если бы вы описали проюлему более подробно (что конкретно не работает - эксепшн какой, или что-то еще) - было бы понятней.

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

leftJoin же - это тупо чтоб приджойнить таблицу в, так сказать, ручном режиме. Он ничего не знает о релейшенах, о том что что-то нужно выбрать - он тупо джойнит таблицу и все. Соответсвенно, ничего и не выбирает.

Если хотите чтоб автоматом выбирал - работайте через релейшены с with/joinWith

Думаю копать следует в эту сторону https://github.com/yiisoft/yii2/blob/master/docs/g...