mamchyts7 июн 2016 в 10:10

Небольшая особенность CHAR и VARCHAR

3 мин

13K

Комментарии 12

mdl 7 июн 2016 в 10:39

Думается, проблему бы решило

$where = «providerUserId = '?'»;

Потому как в аналогичной ситуации STRICT_ALL_TABLES и прочее нас не спасло.

MySQL знатно неявно кастит числа, да, хотя и услужливо пишет, что за выполнение запроса select * from t where string = 123456 было два предупреждения. Которые по-умолчанию все равно нигде не пишет.

bat 9 июн 2016 в 04:37

Думается, проблему бы решило

$where = «providerUserId = '?'»;

вы уверены что символ вопроса внутри строки будет воспринят как плейсхолдер?

mdl 9 июн 2016 в 04:42

Уже нет.

Как ниже правильно заметили, только явное указание PDO::PARAM_STR в PDO::bindParam решило бы.
А про '?' — глупость сморозил. Просто практически никогда не связывался с prepared statements в клиентских приложениях.

bat 9 июн 2016 в 04:50

не связывался

а зря
говорите как будто это бяка какая-то ))
весьма полезная штука

автора за подобный код осуждаю

$where .= ' AND provider = "'. $provider. '"';

возможно, что там значение из предопределенного списка констант, и тем не менее

mamchyts 9 июн 2016 в 05:02

Согласен, не хорошо мешать, в данном случае $provider — это предопределенный список, так что ничего ужасного не будет.
Просто на тот момент кто-то поленился создавать отдельный массив для параметров, а $provider не обязательный.

miksoft 7 июн 2016 в 10:50

Мне казалось что это широко известная фича MySQL, что он кастит строки в числа от начала строки до первого неподходящего символа.

А вообще есть хорошее неписанное правило — не полагайтесь на неявные преобразования типов. Сравнивайте строки со строками, а числа с числами.

mamchyts 7 июн 2016 в 10:53

Насчет фичи не соглален, впервые с таким столкнулся, это же не поиск а ля LIKE 'xxxx%' .
А вот со вторым — полностью согласен, хотя в данном примере я положился на PDO, и как видно зря…