Mysql The best PDO wrapper

Всегда считал, что в случае НЁХ надо выдавать ошибку 500.
Обрыв соединения не является НЁХ

Есть две ошибки после успешного соединения, в результате которых нефиг выдавать 500:
1. MySQL server has gone away
2. Lost connection to server during query

К тому же, если тебе не удалось законнектится 1 раз к серверу, то это не повод отбрасывать коньки, если есть дублирующий, например.

Все это делается элементарно через исключения, только либа должна уметь их выбрасывать в осмысленном виде.
 
А разве PDO сам не реконнектится?... Что-то я такое там припоминаю.
 
Не реконектица. И способов его зареконектить кроме как создавать новый объект я не нашел.
 
Есть две ошибки после успешного соединения, в результате которых нефиг выдавать 500:
1. MySQL server has gone away
2. Lost connection to server during query
Почему? Хочу услышать еще мнение других девелоперов по этому поводу.
Сам считаю, что однозначно 500 в таких случаях.
 
Absinthe, потому что это ожидаемое поведение. Точнее этой ошибки можно ожидать и отреагировать на нее по разному.
 
Почему? Хочу услышать еще мнение других девелоперов по этому поводу.
Сам считаю, что однозначно 500 в таких случаях.
Не www один существует. У меня был демон, а мускуль рвал соединение через какое-то время неактивности.
А вообще, если есть возможность дать клиенту ответ, а не 500, лучше это сделать. Другое дело, что в www вероятность этого не очень велика.
 
Не реконектица. И способов его зареконектить кроме как создавать новый объект я не нашел.
Наверное, я неправильно поставил вопрос...
Сам по себе PDO объект конечно не, мало ли, может БД в принципе не под?...
Но, например, в PDO::MySQL есть такая ссылка:
PDO::MYSQL_ATTR_INIT_COMMAND (integer)

Command to execute when connecting to the MySQL server. Will automatically be re-executed when reconnecting.

Note, this constant can only be used in the driver_options array when constructing a new database handle.
 
Не www один существует. У меня был демон, а мускуль рвал соединение через какое-то время неактивности.
А вообще, если есть возможность дать клиенту ответ, а не 500, лучше это сделать. Другое дело, что в www вероятность этого не очень велика.
Не велика, но она есть даже в www.

@Absinthe В 99% случаев она не встретится, да. Но когда это начнет происходить, лучше иметь соответствующий инструмент(исключения соответствующего типа), пока сетевики, например, разберуться почему начали пропадать пакеты.
К тому же, 500 -- это фактически фатал. Однократная потеря соединения с БД -- не фатал для приложения. Вот пару раз подряд -- уже повод для беспокойства.

Понятное дело, что для показа новостей про хомячков это не критично, но для более важных вещей может быть крайне полезно, если неохота деньги терять.
 
  • Возможно какой-то хак с биндингом массивов
А почему ты его не сделал, кстати? И идентификаторы.
Ты же все равно парсишь запрос. Я так и не понял, почему ты решил остановиться только на поддерживаемых типах.
Из-за невосместимости с множественным исполнением? Кидай исключение. Хотя да, этот вопрос надо продумать.

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

А вообще я полез в него посмотреть, поддерживаешь ли ты дефолтные плейсхолдеры вида ? и :name, без типов, трактуемые по умолчанию как строки. Без такой фишки либа будет неюзабельна.
 
Последнее редактирование:
И, кстати, ни одна зараза не указала на РЕАЛЬНО ЖУТКИЙ КОСЯК, который влёгкую похерит пол-базы - насильный кастинг в число всего, что похоже на число.
Код:
SELECT * FROM table WHERE username = 0
ога?
скрипя сердцем, выкинул оную фичу.
 
Последнее редактирование:
И, кстати, ни одна зараза не указала на РЕАЛЬНО ЖУТКИЙ КОСЯК, который влёгкую похерит пол-базы - насильный кастинг в число всего, что похоже на число.
Код:
SELECT * FROM table WHERE username = 1111
ога?
скрипя сердцем, выкинул оную фичу.
гг, я хотел спросить, потом почитал обсуждения, смотрю что вы серьезно так это обсуждаете, решил,что я туплю и чего-то не понимаю, и промолчал)))
 
Фанат, массивы я добавлю, возможно. идентификаторы - имеешь ввиду названия таблиц/полей? Это на совести пишущего запрос.
:name - спорный вопрос. Мне кажется лучше очевидно указать, что это будет строка.
По поводу int - я когда-то предлагал такое:
PHP:
if ((int) $value == $value) {
  $stmt->bindParam($param, $value, \PDO::PARAM_INT);
}
 
Фанат, массивы я добавлю, возможно. идентификаторы - имеешь ввиду названия таблиц/полей? Это на совести пишущего запрос.
:name - спорный вопрос. Мне кажется лучше очевидно указать, что это будет строка.
По поводу int - я когда-то предлагал такое:
PHP:
if ((int) $value == $value) {
  $stmt->bindParam($param, $value, \PDO::PARAM_INT);
}
$value = "000999";
 
идентификаторы - это на совести пишущего запрос.
Не понял этой фразы. А строки - не на совести? А почему?
:name - спорный вопрос. Мне кажется лучше очевидно указать, что это будет строка.
совместимость сразу подскакивает в разы - не надо каждый запрос переписывать.
По поводу int - я когда-то предлагал такое:
В-первых, если бы это сработало, то был бы тот самый адов косяк с удалением половины базы, о котором я говорил.
Во-вторых - к счастью, это не будет работать в режиме эмуляции. А в нативном оно нафиг не нужно
 
Фанат, идентификаторы на совести потому что либа маленькая и мне не хочется изучать как в mssql, например, надо их писать и экранировать. Ну и потому что их биндить не стоит, на мой взгляд.
скрипя сердцем, выкинул оную фичу.
Кхм)) и от либы остался кусок сомнительного синглтона))
 
биндить не стоит, на мой взгляд.
Вот именно это странное убеждение я и хочу побороть последние года два.
Даётся с трудом.
остался кусок сомнительного синглтона))
Ну, в общем, да.
Кроме чисто объектного пыха, всё ещё существует и поцедурный.
 
Фанат, ну хорошо, а зачем биндить идентификаторы? Какой в этом смысл?
Если бы был какой-нить кверибилдер, можно к нему такое прикрутить:
PHP:
$qb->setAllowedColumns(['id', 'username', 'email', 'age', 'sex'])
    ->select($request->request->get('columns'));
А биндя идентификаторы, если так сделаешь без этого метода - можно получить, например любые данные о юзере
 
Сверху