Да, но проблема в том, что работа с БД не стала безопаснее.
То есть, такой перенос попросту не имеет смысла.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Класс для безопасной работы с MySQL
- Автор темы Фанат
- Дата начала
То есть, такой перенос попросту не имеет смысла.
karnas
Новичок
Т.е. даже если по логике должна вернуться одна строка, все равно нужно использовать limit?
Лимит здесь совсем не при чем.
Речь о данных, передаваемых в запрос.
просто заменить все вызовы mysql_query на $db->query() не сделает код безопаснее ни на йоту
karnas
Новичок
Я конечно практически новичек в этом деле, но зачем статические данные выносить на фильтрацию?
Динамические естественно передаю на фильтрацию ?i, ?s и т.д.
К примеру в этом запросе одна динамическая переменная, все остальное статика. Да и запрос выполняется напрямую из скрипта и с POST-GET запроса его не выполнить, что бы изменить второе условие u.time_zone = t.id. Расскажите в чем я ошибаюсь если не трудно.
PHP:
$db->getRow("SELECT * FROM users AS u JOIN time AS t ON u.site = ?s AND u.time_zone = t.id", $site)Статические не нужно.
если так - то да ,все правильно. Просто я не увидел, чтобы функция paginate() поддерживала передачу параметров. Соответственно, предполагаю, что запрос в нее пердедается по-старинке, вместе с данными. Ведь это же функция общего назначения, не только для этого одного статического запроса?
Последнее редактирование:
karnas
Новичок
Вырезка из paginate.
Передается через GET одна переменная - номер страницы.
Устанавливаем номер страницы по дефолту 1. Т.е. если ошибка, вернет данные первой страницы.
Далее узнаем количество записей всего, делим на нужно количество записей на стр., получаем количество страниц.
Используется статический запрос.
Далее выборка из бд. Даже тут по идее данные для лимита можно было не выносить на фильтрацию,
так как единственная числовая переменная уже фильтровалась выше. На этом работа с mysql в paginate закончена.
PHP:
var $turn = 1;
if (isset($_GET['turn'] )) {
$turn = intval($_GET['turn'] );
if ($turn){$this->turn = $turn;}
}
$all_rs = $db->query($this->sql );
$this->total_rows = $db->numRows($all_rs );
if ($this->turn > $this->max_pages || $this->turn <= 0) {
$this->turn = 1;
}
$this->offset = $this->rows_per_page * ($this->turn - 1);
$rs = $db->query($this->sql .' LIMIT ?i, ?i',$this->offset, $this->rows_per_page);
if (! $rs) {
if ($this->debug)
echo "Pagination query failed. Check your query.<br /><br />Error...";
return false;
}
return $rs;Для этого запроса - да.
А для других этот класс не используется?
я уже писал выше, что выбирать все записи в таблице только для того, чтобы посчитать их - это АДЪ и убьет тебе сервер
Непонятно тогда, зачем класс городить.
Не понимаю, о каком лимите ты все время говоришь.
Задача - запросить количество строк у базы. Не лимит добавить, а количество строк запросить. Неужели непонятно?
karnas
Новичок
Ход мыслей верный?) SQL_CALC_FOUND_ROWS вернет общее количество строк, в след. запросе забираем общее количество строк.
Далее уже будет запрос с лимитом для получения записей с 1-й страницы по дефолту и вывод разбивки по страницам.
PHP:
$sql = "SELECT SQL_CALC_FOUND_ROWS * FROM table where DATE(date) = DATE(NOW()) ORDER BY date DESC";
///
$all_rs = $db->query($this->sql );
///
$this->total_rows = $db->getOne("SELECT FOUND_ROWS()");Да.
Я не очень люблю лезть в готовые запросы, но здесь, похоже, без строковой замены не обойтись. Впрочем, большой беды я не вижу.
да, ход верный, отлично идет, жаль, конечно, что ошибка в генах немного сбила направление эволюции
Плюсы ты более-менее описал.
Главный минус тут в том, что в $query может быть куча join'ов, подзапросов и т.п., которые нужны для выборки данных, но не влияют на количество возвращаемых строк.