Это сознательное допущение E_NOTICE. Умалчивание ошибки не означает, что ее там нет. И когда там возникнет E_WARNING, или любая другая, не предусмотренная ранее ошибка, в логах тоже ничего не будет. В этом заключается опасность использования «собаки».
А зря. Мне этот оператор изрядно попортил настроение при попытке отладки старенького сайта по логам. Особенно когда он ставился перед файловыми операциями вместо file_exists.
Впрочем, не лучше. Блендинг с градиентами, оказалось, пока ещё довольно глючная вещь, особенно в ФФ (как ни странно), и особенно если их надо динамически растягивать.
Пул должен сам это делать, это входит в его обязанности.
Функция done() в pg делает соединение свободным для следующего запроса (но не разрывает его, разумеется).
Если вы используете mysql, что наверное пул будет отсюда, и функция будет connection.end().
Если соединение не уходит в пул (драйвер кривой или вы не завершаете работу с сединением после получения ответа на запрос), то возможны два варианта:
1. Если вы установили лимит подключений, то после количества запросов === размеру пула будет блокировка работы с БД.
2. Если вы не установили лимит пула, то будет рост количества подключений до бесконечности / количетсва разрешенных дескрипторов.
Если все сделано нормально, то в ходе работы в конечном счете должно быть установлено количество соединений с базой, равное размеру пула, которое не будет изменяться в процессе работы сервиса.
Что касается «моментов выхода» — я их делаю в модели, по мере необходимости, после каждого запроса или транзакции и с вьюхами это никак не связано. Соединение в пуле остается «живым» (в частности, это дает возможность использовать prepared statements, что дает сильный прирост производительности). Закрывать соединение после каждого запроса я бы не рекомендовал.
Ради этой иерархии весь сырбор и затевается. Так, например, PDO или Memcached могут бросать свои исключения, и их можно ловить отдельно и что-то с ними делать, например писать в лог. Но слишком большую иерархию делать нет смысла — будет хаос из классов и рутина в поддержке этого ансамбля.
Поскольку «какая-нибудь ошибка», о которой забыл разработчик, будет являться наследником ApiException, то она поймается так или иначе на нижнем уровне, и «бээ» не будет. А вот писать после кажого вызова «if ($result !== false)» надоест уже после первой недели работы с кодом.
Полностью согласен, решение подходит для ограниченного круга задач, где требуется произвольное распределение, число вариантов выхода дискретно и невелико, а настройки вероятностей не слишком плавные.
Особняком, конечно, стоит «Downloads». Это место захламляется чаще всего, потому касательно него есть правило: если файл оттуда не перенесен в специализированное место, значит он больше не нужен. И вообще, если что-то откуда-то слито, значит, наверняка можно скачать ещё раз. Поэтому «Downloads» можно вычищать как корзину раз в неделю и не беспокоиться о том, что будет что-то потеряно.
Верно, но такие ситуации бывают и вводят в ступор, особенно новичков, так как явной проверки на ноль и undefined здесь нет. И синтаксис не всем понятен такой :)
При этом в arg2 и arg3 передать ноль уже не получится. В случае, когда ноль — допустимое значение, всё равно придется делать проверку на undefined. Это нужно иметь в виду.
При использовании == есть вероятность что кто-то этим злоупотребит и начнет присылать вместо числа строку с нулем или вообще пустую строку или false. Это приводит к багам и трудностям отладки. А undefined многие рекомендуют даже проверять через typeof, так как некто может переопределить undefined в данном контексте (var undefined = 'something'). Это конечно сферические случаи в вакууме, но от таких багов лучше подстраховываться. Вообще это тема для отдельного разговора, на хабре он бывал.
