Спасибо за комментарий. Большинство моментов исправил.
Зачем? У Вас там массив, пусть error всегда будет, чтоб на количество его проверять, а не на наличие, а потом на количество
Тут решение такое, что если есть ошибки, то добавить ключ, а смысла проверять количество после проверки наличия — не вижу. Вот такое решение можно сделать для вашего случая:
if (array_key_exists('success', $migrations)) {
foreach ($migrations['success'] as $successMigration) {
Console::writeLine("Миграция {$successMigration['name']} успешно применена", Console::FG_GREEN);
}
}
if (array_key_exists('error', $migrations)) {
foreach ($migrations['error'] as $errorMigration) {
Console::writeLine("Ошибка применения миграции {$errorMigration['name']}", Console::FG_RED);
Console::writeLine($errorMigration['errorMessage'], Console::FG_WHITE);
}
}
Что такое 'относительно всех'?
Если стоит 0, то применяются все возможные миграции. То есть, действие совершается относительно всех миграций.
Что если мне нужно свалиться на первой неуспешной миграции, а не идти до конца?
PHP 5.2.X по PSR немного другие именования классов, по этому было сказано про PHP 7. Yii2 был приведен в качестве примера, а не эталона. Согласен с Вами, что для AR использование snake_case актуально, но для реализации не AR свойств, по моему мнению, не корректно. Именование namespace я бы рекомендовал оформлять так, как именуются папки проекта.
Поверхностно, да. Я хотел поговорить именно по прочитанному материалу, не отходя в дебри размышлений, хотя это стоило сделать. Учту в следующих материалах.
Вы не соблюдаете синтаксис работы с ini файлами. Написать проверку на ключи можно, а на значения нет смысла. В значение может быть и строка и цифра и символы. Этот момент был оставлен на отмашку пользователя класса.
Вы можете скачать код этот и внедрить к себе в проект. Как минимум — это ознакомительная часть, может кому понадобиться для реализации своих идей. Можно было оформить в качестве пакета, но позже сделаю это.
Лучше всего было выложить код сюда и объяснить его. Вы заставляете людей переходить на другой сайт, чтобы понять о чем речь. Оставьте просто ссылку на исходник, а код покажите в статье и объясните. Было бы хорошо иметь наглядную схему потоков данных и процессов.
Да, в схеме не очень корректно отобразил. Сервис отдает данные, но не обращается к контроллеру с просьбой что-то сделать. Надо было разделить стрелки на запросы и ответы.
Без них непонятно чем Entity отличается от Model
В моем представлении Model отражает таблицу базы данных и оперирует запросами к ней. В случае таблиц справочников, где данные не могут изменяться пользователями системы, в моем представлении, нет смысла создавать такую таблицу. Следовательно, модель не нужна, а сущность реализует статичное хранение данных на стороне сервера приложения.
Там ответ на вопрос о разности
iи_. Выше, указывали, что_не хранит в себе данных. А по ответу на стаке видно полное описание_.В комментарии есть ответ на ваш вопрос: https://stackoverflow.com/a/5893946/4772782
Да, спасибо.
Тупо рандомное письмо на почте
Тут решение такое, что если есть ошибки, то добавить ключ, а смысла проверять количество после проверки наличия — не вижу. Вот такое решение можно сделать для вашего случая:
Если стоит 0, то применяются все возможные миграции. То есть, действие совершается относительно всех миграций.
Этот момент и так уже реализован:
Что у вас за приколы, ставите минус, а комментариев нет... Хоть объясните почему так))
Тут есть рекомендация в PSR-1
На этот счет я отмечал в своей статье PHP Code Style Conventions
Поверхностно, да. Я хотел поговорить именно по прочитанному материалу, не отходя в дебри размышлений, хотя это стоило сделать. Учту в следующих материалах.
В моем представлении Model отражает таблицу базы данных и оперирует запросами к ней. В случае таблиц справочников, где данные не могут изменяться пользователями системы, в моем представлении, нет смысла создавать такую таблицу. Следовательно, модель не нужна, а сущность реализует статичное хранение данных на стороне сервера приложения.