Прекрасный ответ, три лайка.
И ни слова про инвалидацию, которую MySQL делает сама, без участия человека. То есть всегда возвращает актуальные данные.
А самопальный кэш на редисе будет всегда возвращать старьё.
"Заказ? Какой-такой заказ? Вот все заказы, которые вы делали, нет тут последнего. Заказывайте снова!"
давно я не читал таких смешных оправданий
"причиной оказался не mysqli, а catch", но при этом " я запутался и забил на экранирование"
В таких случаях в народе говорят "дело было не в бобине..." ;-)
nokimaro, здесь же важен момент обучения.
У автора уже есть многие элементы такого враппера.
Дальше он будет его собирать в класс.
easydb хороша, я там даже поучаствовал по мелочи. Но для изучения он уже великоват. а польза от пользования системой, которую не понимаешь, довольно сомнительная.
Во-первых, сам подход правильный, программистский.
Для программиста как раз написание такой функции - это норма.
Вот если не возникает идея написать такую функцию вообще - то тут уже возникают очень большие вопросы насчет правильности выбранной профессии.
Сама функция неплохая, у меня только два замечания
Во-первых, лучше все-таки потихоньку переучиваться на то, чтобы $dbpdo передавать в параметрах. Я понимаю, что global удобнее, но с ростом сложности кода это наоборот будет минусом.
Во-вторых и самое главное - как я и писал, надо защищать имена таблицы и полей
Хотя бы с помощью простых строковых функций.
и прогонять через неё имя таблицы и все имена полей.
так в принципе тоже сохраняется опасность. Например в таблице users есть поле admin. И если со стороны передадут такое поле, то юзера сделают админом. поэтому лучше всего проверять поля по списку разрешенных.
Vitsliputsli, ну в реальной практике не обойтись без использования имён полей на основе пользовательского ввода.
Самый простой пример - сортировка. Плюс довольно частая задача по обновлению только заполненных пользователем полей, и выбрасыванию пустых - чтобы не затереть пустыми значениями уже имеющуюся информацию.
jazzus, на самом деле вы оба правы.
просто валидаций может быть больше чем одна.
Для бизнес-логики тоже приходится валидировать.
Если рассуждать в терминах "Какая может быть ситуация", то тогда и строгая типизация в пхп тоже не нужна. "Ну откуда там другие типы возьмутся, если ты сам все данные заполнял?"
jazzus, зато имеет к SRP.
Но понимание этого приходит с опытом.
Я "двойную валидацию", которая на самом деле не двойная, поддерживаю двумя руками.
Валидация пользовательского ввоба - это одна задача, валидация модели - другая. Да, они пересекаются. Но это не повод вообще никак не валидировать модель
