montray

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

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

Проверять обращения к БД не нужно вообще

(за исключением нескольких специальных случаев, когда есть определенный сецнарий обработки ошибки)
Если же такого сценария нет, то никак проверять не нужно. Просто потому, что обращения к БД ничем не отличаются от любого другого кода.
И поскольку ты не проверяешь каждый include или там оператор деления, то не нужно и проверять запросы к БД. Их надо оставить в покое. И первый, и каждый по отдельности, и все 5 разом.

А вот что нужно сделать - это договориться с РНР, чтобы он сам сообщал тебе об ошибках в запросах. Для mysqli надо написать перед коннектом

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

Для ПДО при соединении выставить в настройках соединения

PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION

Всё. Больше ничего для обращений к БД делать не надо.

А вот обработчик ошибок, общий для всего кода, а не только для работы с БД, настроить желательно.
Чтобы AJAX-скрипт подписки получал соответствующий НТТР статус при любой ошибке, которая может возникнуть на сервере.
Ну и разумеется AJAX-скрипт подписки должен проверять НТТР статус, и обрабатывать ответ только если статус= 200
Пример обработчика можно посмотреть здесь

Если же надо убедиться, что все пять запросов выполнились без ошибок, то для таких целей служат транзакции.
Суть транзакции именно в том, что либо выполнияются либо все запросы, либо ни одного.
Если заключить все 5* запросов в транзакцию, то если при выполнении одного из них произойдет ошибка, то изменения, сделанные остальными, автоматически откатятся!

*На самом деле в транзакцию имеет смысл заключать только запросы, изменяющие данные. То есть все, кроме первого.

Соотсветственно, если ПДО настроен на выброс исключений, то при ошибке запроса
- пдо выбросит ислючение
- которое будет поймано обработчиком ошибок
- который выведет код ошибки и завершит работу РНР скрипта
- при завершении скрипта РНР закроет соединение с БД
- БД при закрытии соединения автоматически откатит незавершенную транзакцию

причем без обработчика ошибок будет всё то же самое, только клиенту уйдет код не 500 а 200

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

1. выставить для ПДО режим исключений
2. перед первым запросом написать $pdo->begin();
3. после последнего запроса написать $pdo->commit();

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

Хотя ответ очень простой и первый вопрос автора даёт очень простую подсказку.

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

То есть к самому приложению, если подумать, отношения не имеет.

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

При этом модель - это не убогий интерфейс к таблице в бд, как думают все попугаи. А собственно все приложение и есть. Это ещё называется бизнес-логикой.

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

Ответ с картинками и видео с ютюбе https://qna.habr.com/answer?answer_id=1475989#answ...

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

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

select *
from `user` `u`
join `property` `p`
left join `user_property` `up` on `up`.`user_id` = `u`.`id` and `up`.`property_id`=`p`.`id`
where `up`.`id` IS NULL

Можно просто выключить адблок и увидеть ответ