fomiash / Фома Тутуров ²²¹

PS Отдаю должное генератору картинок, он творчески подошел к задаче, я попросту скормил ему весь это текст, и он точки А, B и С ловко обозначил как Бермудский треугольник.

[1] Внешние ключи — это определенный тип ограничения, который используется для создания связи между двумя таблицами. Он указывает, что значение определённого столбца (или группы столбцов) в одной таблице должно соответствовать значению первичного ключа в другой таблице.

Это позволяет:

1. Сохранять целостность данных: если вы попытаетесь добавить значение во внешнем ключе, которое не существует в родительской таблице, это вызовет ошибку.

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

[2] Ограничения (constraints) — это правила, которые задаются на уровне таблиц в базе данных для обеспечения корректности и целостности данных. Они помогают предотвратить ввод некорректных данных в таблицы. Типы ограничений включают:

1. PRIMARY KEY (первичный ключ): обозначает уникальный идентификатор записи в таблице. Каждая таблица может иметь только один первичный ключ.

2. FOREIGN KEY (внешний ключ): устанавливает связь между двумя таблицами, указывая, что значение в одном столбце должно соответствовать значению в столбце другой таблицы.

3. UNIQUE: обеспечивает уникальность значений в столбце, позволяя хранить только уникальные записи.

4. NOT NULL: гарантирует, что в столбце не может быть NULL значений.

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

Дополню про разницу между \Closure и callable если они используются для типизации. Разница в том, что при Closure функция должна быть анонимной, тогда как callable может быть и обычной функцией. Пример:

<?php
// Пример кода с Closure (обратите внимание, что можно написать и с маленькой буквы).
function expectClosure(closure $closure) {
    $closure();
}
// Пример кода с callable типом.
function expectCallable(callable $callback) {
    $callback();
}
// Пример обычной именованной функции.
function foo() {
    echo 'Named function executed!' . PHP_EOL;
}
// Пример анонимной функции.
$anonymous = function () {
   echo "Anonymous function completed!" . PHP_EOL;
};

expectClosure('foo'); // TypeError: Argument #1 ($closure) must be of type closure, string given
expectClosure($anonymous); // Anonymous function completed!
expectCallable('foo'); // Named function executed!
expectCallable($anonymous); // Anonymous function completed!

Сделать это просто, наподобие того как в Laravel вешается объявление:

// Файл public/index.php

// Determine if the application is in maintenance mode...
if (file_exists($maintenance = __DIR__.'/../storage/framework/maintenance.php')) {
    require $maintenance;
}

Если такой файл $maintenance есть, то есть заглушка, достаточно его держать в локальной разработке, скачивать на сервер и потом уже файлы заливать, потом удалять его. В данной ситуации этот вставляемый файл должен содержать exit() в конце. Есть еще блокировка консольной командой, но у вас возможно нет доступа к консоли.

Для удаления раздела Каталог на сайте:

1. Удалить ссылки на каталог из меню в файле: /resources/views/default/_block/navigation/config/left-menu.php

2. Удалить папку с файлами: /routes/catalog/

3. Обновить кеш маршрутов, если необходимо (удалением папки /storage/cache/routes/).

При оборачивании в транзакцию нескольких программных сервисов или иного вложенного кода, стоит учитывать, что:

1. Внутри этих сервисов может быть привязано событие или иной триггер, которое отработает как успешное в то время как транзакция будет отменена. Например, может быть отправлено сообщение пользователю на E-mail или иным способом.
2. Вызов фонового события внутри транзакции или обращение к другому сервису не может быть отменено вместе с транзакцией.
3. Транзакция в транзакции. Возникает неочевидное поведение в различных БД при использовании rollback, теряется атомарность, если внутренняя транзакция уже сохранена, а внешняя нет (в MySQL это будет считаться одной транзакцией).
4. Неуспешная отработка сервиса или иного кода внутри транзакции может быть не очевидна для отката транзакции.
5. Слишком строгий уровень изоляции транзакций при сложных процессах внутри самой транзакции может послужить причиной задержек выполнения.

MyRocks, движок хранения к СУБД MySQL от Facebook

Facebook запустил проект MyRocks, который включает новый движок хранения для системы управления базами данных MySQL 5.6. Он основан на RocksDB и оптимизирован для использования с Flash-накопителями. Основными задачами MyRocks являются улучшение эффективности хранения данных на Flash-носителях и уменьшение объема базы данных.

В InnoDB основными факторами, способствующими большому потреблению дискового пространства, являются фрагментация, низкая степень сжатия и фиксированный размер страниц для хранения данных (8 КБ). Даже если данные занимают 5 КБ, блок размером 8 КБ все равно будет расходоваться. В отличие от этого, MyRocks использует плавающий размер страниц и предлагает более эффективный метод сжатия. Кроме того, MyRocks требует меньше операций последовательного чтения и записи благодаря модели хранения данных на основе логов (Log Structured Merge Trees), которая допускает только добавление данных, а очистка выполняется сборщиком мусора.

Внедрение нового хранилища на основных серверах Facebook для хранения аналогичного объема данных позволило сократить размер базы данных на 50% по сравнению с сжатым хранилищем InnoDB и в 3,5 раза по сравнению с InnoDB без сжатия. Также использование MyRocks привело к ускорению процесса репликации за счет снижения количества операций чтения при обновлении ключей. Операции загрузки данных в базу тоже стали быстрее благодаря пакетной обработке.

Однако MyRocks имеет некоторые ограничения, такие как отсутствие поддержки внешних ключей, онлайн DDL, автоматического определения взаимных блокировок, партиционирования, а также полнотекстовых и пространственных индексов. В будущем предполагается устранить эти недостатки.

Репозиторий: https://github.com/facebook/mysql-5.6

В совокупности с неинтуитивным роутингом в YII

В Yii3 обещается более удобный роутинг, чем в предыдущих версиях, похожий на роутинг Laravel.

PS Возможно, что будет нужна функция Hleb\Static\System::getTaskPermissions() для того, чтобы определить заранее, может ли конкретная задача выполняться в нужном режиме.

UPD Если изменить маршрут на:

// Файл /routes/main.php
Route::any('/{controller}/{method}')
    ->module('common', 'Modules\Common\Controllers\<controller>Controller@action<method>');

то будет более полная подстройка под Yii2, так как теперь только методы контроллера начинающиеся с "action" будут участвовать в подборе совпадений. Например, адрес /site/index будет указывать в контроллер модуля SiteController и его метод actionIndex(). При этом в rules() останется по прежнему ключ 'index' в данном случае.

Часть подобных статей вынес в раздел "Вопросы", с недавнего времени он также пополняется категорией FAQ, так что велком.

Нужно настроить права на папку storage по этой инструкции https://hleb2framework.ru/ru/2/0/settings

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

Если ваше приложение будет работать с базой данных, необходимо установить расширение PHP PDO и соответствующий драйвер (например, pdo_mysql для MySQL).

В остальном фреймворк по умолчанию работает с базовым набором расширений PHP. Дополнительно устанавливать ничего не нужно.

Конфигурационные файлы, в том числе для настройки баз данных, хранятся в папке config. Подробнее про конфигурацию https://hleb2framework.ru/ru/2/0/configuration

Для подключения к базе данных MySQL найдите файл config/database.php (или config/database-local.php, если он есть) и измените блок, который по умолчанию имеет название 'mysql.name', также убедитесь, что в 'base.db.type' выставлено это название.

    // База данных по умолчанию:
    'base.db.type' => get_env('DB_TYPE','mysql.name'),
    // Список баз данных:
    'db.settings.list' => [
        'mysql.name' => [
            'mysql:host=localhost',
            'port=3306',
            'dbname=%dbname%', // Название базы данных
            'charset=utf8',
            'user' => '%username%', // Имя пользователя
            'pass' => '%password%', // Пароль
        ],
    ]

Об уровне подачи информации у этой организации можно судить по статье на Хабре . За эту статью упомянутая там компания подала в суд и пришлось срочно вносить в статью изменения. Неужели хваленые юристы профсоюза ничего в статье не обнаружили перед выкладкой? Делайте выводы.

Эти две версии отличаются очень сильно, но просматривается приемственность.

В общем - HLEB1 поддерживает версии php 7.2 - 8.2 и на текущий момент не развивается, только поддержка безопасности.

Все силы направлены на HLEB2, этот фреймворк современнее, в нем учтены нюансы разработки первого фреймворка и он имеет более расширенные возможности.

Вот связанные посты на эту тему:

Переход на HLEB2 c первой версии фреймворка

Отчет по подготовке версии HLEB 2.0

Вместо отчёта по фреймворку HLEB 2

Заметки о переделке фреймворка HLEB

В преддверии версии фреймворка HLEB 2.0

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

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

Недавно читал перепалку программистов, что преимущество Symfony перед другими PHP-фреймворками как раз в том, что Symfony не позволяет писать "плохой" код. Как раз описанный выше проект на этом фреймворке, что показывает, что фреймворк не может повлиять на качество кода разработчика, и дело совсем не в инструментах, а какие руки эти инструменты держат.