-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Не работает num_rows в mysqli, если использовать IN
- Автор темы BelStudent
- Дата начала
Mols
Новичок
Вроде в топике речь не о библиотеке.
З.Ы.
Относительно требующая или нет - честно говоря я никаких противоречий не вижу. Библиотека честно отрабатывает со всеми необходимыми типами данных. Где там "декларировано" что она должна работать с ИНТ(и не только) перечисленными через запятую я честно говоря не видел. Может ссылка есть?
З.Ы.
Относительно требующая или нет - честно говоря я никаких противоречий не вижу. Библиотека честно отрабатывает со всеми необходимыми типами данных. Где там "декларировано" что она должна работать с ИНТ(и не только) перечисленными через запятую я честно говоря не видел. Может ссылка есть?
tf
крылья рулят
prepare не работает с массивами, этим грешит и pdo, насколько я помню ему это в минус приводили
но она и не предназначена для placeholder, она предназначена для подстановки данных в кучу повторяющихся запросов, видимо автор не считает что там нужны массивы, хотя и зря
но если вы их используете как плацехолдеры то что вам мешает поступить правильно - переписать bind_param (что на си) и написать в баг трек об этом?
но она и не предназначена для placeholder, она предназначена для подстановки данных в кучу повторяющихся запросов, видимо автор не считает что там нужны массивы, хотя и зря
но если вы их используете как плацехолдеры то что вам мешает поступить правильно - переписать bind_param (что на си) и написать в баг трек об этом?
Mols
Новичок
Ну вот в том и дело, что оно не декларировано.
И не может быть такая чушь декларирована.
Потому как не определено, как вообще должны хранится данные для подстановки в IN. Это может быть как массив, так и набор ртдельных переменных. Это могут быть данные разного типа. Поэтому программист сам должен позаботится о подстановке этих данных в запрос. И это вполне соответствует здравому смыслу. Потому как все инструменты для этого библиотека предоставляет. А в том, чтобы всунуть один плейсхолдер в запрос, и потом удивляться, что библиотека не знает, что там засунуто в какой-то массив.... но это очень блин здраво)))
И не может быть такая чушь декларирована.
Потому как не определено, как вообще должны хранится данные для подстановки в IN. Это может быть как массив, так и набор ртдельных переменных. Это могут быть данные разного типа. Поэтому программист сам должен позаботится о подстановке этих данных в запрос. И это вполне соответствует здравому смыслу. Потому как все инструменты для этого библиотека предоставляет. А в том, чтобы всунуть один плейсхолдер в запрос, и потом удивляться, что библиотека не знает, что там засунуто в какой-то массив.... но это очень блин здраво)))
findnext
Новичок
напрямую выполнить запрос без препаре.
-~{}~ 02.08.09 20:20:
биндить есть смысл когда данные идут от пользователя. Насколько я понимаю в данном контексте ид будут выбираться из бд. Почему нельзя выполнить напрямую запрос?
-~{}~ 02.08.09 20:22:
никак, а нужно ли это вообще в библиотеке?
-~{}~ 02.08.09 20:23:
Mols
у тебя часто разные типы данных подставляются в IN (в перемешку INT, STRING)?
вроде уже обсосали все ранее?
1. Что за бред с "число+строка в IN"? Считаем ВСЁ строками. ВСЁ слешим и в кавычки. Это все. Единственное исключение - NULL.
2. Какая нахрен разница, данные в IN от юзера или из базы? Чтоза бред? Из базы никогда не читаются данные от того же юзера, записанные ранее, и слешить или подставлять в кавычки не нужно?
1. Что за бред с "число+строка в IN"? Считаем ВСЁ строками. ВСЁ слешим и в кавычки. Это все. Единственное исключение - NULL.
2. Какая нахрен разница, данные в IN от юзера или из базы? Чтоза бред? Из базы никогда не читаются данные от того же юзера, записанные ранее, и слешить или подставлять в кавычки не нужно?