Ошибка запроса базы данных Codeigniter - не возвращает ожидаемых результатов

Question

Я проверил этот запрос в своей базе данных, и он отлично работает:

select * from variables where value = 'commas-:-)';

Я получил результат.Теперь я сохранил значение в переменной и использую класс запроса.

$value = 'commas-:-)' <<< это передается как параметр </p>

$query = "select * from variables where value = '$value'";
$this->db->query($query);

Теперь этот запрос работает для всех остальныхзначение, кроме этого, но странно то, что если я ПЕЧАТЬ точный запрос (print_r из $query) и выполнить его в базе данных, он вернет правильный результат.Поэтому мне остается думать, что класс запроса искажает мой запрос, чего не должно быть, потому что все правильно экранировано и $value является строковым литералом.

Что происходит?

Answer 1

$get_data = $this->db->from('variables')
                      ->where('value', $value)
                        ->get();

Надеюсь, это сработает ...!

попробуйте использовать эти вещи для проверки запросов

echo $this->db->last_query();

print_r($this->db->result_array($get_data));

Answer 2

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

Вот что произошло:

Я создал привязку с закодированным значением (запятые :-)) и настроил маршрут, чтобы перенаправить URI к функции, которая была в моем контроллере.Каждый раз, когда я щелкаю ссылку, значение передается и (предположительно) перенаправляется в функцию.Что он и сделал, почти для всех значений, которые я использовал.Кроме этого.

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

2-е предположение: данные должны быть повреждены - хотя значение верное (я получаю запятые :-)), ничего не возвращается, кроме случаев, когда я набираюв значение вручную.Итак, я проверил это: я создал отдельное значение и установил его равным тому, которое я набрал (тот, который работает).Затем я распечатал исходное значение (переданное) и вновь созданное значение, используя VAR_DUMP.Оказывается, значение аргумента (которое не работает) - это строка длиной 14, тогда как моей новой переменной была строка длиной 10. WTF?Вывод: что-то произошло во время процесса изменения маршрута / изменения, которое изменило переменную.

Я вернулся в папку конфигурации и заменил переменную $ i в перенаправлении на запятую строкового значения :-).И угадай что?Это сработало отлично.И просто чтобы убедиться, что это не регулярное выражение, я написал свое собственное регулярное выражение, и оно отлично подошло, но значение все еще менялось.Вот и я решил забраться под капот.

Я проследил манипулирование URI в классе маршрутов функцией _explode_segment (), которая использовалась для выполнения регулярных выражений и анализа uri для других переменных.Он также сделал это ...

_filter_uri ($ str)

для каждой части сегмента uri, которая была сопоставлена.

Что это сделало?Он заменяет программируемые символы, такие как (и), их HTML ENTITY.Теперь, если вы не знаете, html-объекты имеют большую длину, чем URL-кодирование.ЛОЛ.Итак, что случилось, было:

Оригинальный сегмент: запятые-% 3A-% 29 <- очень приятно!Отфильтрованный сегмент: запятые-% 3A-) <- НООООООООО!(правая часть с кодом).) </p>

urldecode (")") = строка (4) urldecode ("% 29") = строка (1)

Fail.

или ВЫИГРАТЬ?!

Answer 3

$sql = "SELECT * FROM variables WHERE value = ?";
$this->db->query($sql, array('commas-:-)')); 

Подробнее info