это же вопрос предварительной настройки, а я так больше идею описывал. с другой стороны все должно остаться минималически, чтоб новички не парились создавая обьект. те добавить и о то что ты предлагаешь возможноЕсли уж на то пошло, то сам SafeMysql должен быть фабрикой-фасадом, с соединением с базой работает SafeMysqlConnection
Собственно, этот топик как раз навеян именно такими мыслями - сделать ПДО с моими фирменными типизованным блекджеком и однострочными шлюхами.И тут внезапно оказывается, что в итоге написали PDO![]()
Нене, я конкретно про строку SQL.Неважно какой запрос - в php копирование при изменении, "создаваться" будет только сам объект, а оверхед на создание объекта маленький.
Что ты называешь компилятором? Составитель запроса?если компилятор совмещен с парсером - не сделать адаптеро-зависимую генерацию sql, я бы делал в отдельном классе,
это названо фасадомБеда только в том, что не хватает ума спроектировать с фасадами.
$db->getOne(...);
Делаешь примерно как в PDO, без фасада, потом пишешь фасад такой, чтобы было удобно.Беда только в том, что не хватает ума спроектировать с фасадами.
Несчастный парсер - и то не знаю, куда воткнуть
я бы сказал, тут ноги в целом из пхп растут))к примеру, адское поведение prepare(), которое возвращает не стейтмент, а буль. Тут явно ноги растут из неумения пользоваться исключениями.
+1, сволочирвет цепочку prepare(query)->execute(data)->fetch() ровно посередине.
мне в голову приходит только случайНене, я конкретно про строку SQL.
Вот именно, переданные в конструктор параметры не увеличат размер памяти, но созданная строка - увеличит.
поэтому и предлагаю генерить по запросу.
Ты сказал что тебе нужно чтобы запрос генерился или в виде чистого sql, или в виде выражения с нативными плейсхолдерами.Что ты называешь компилятором? Составитель запроса?
Так ты же вроде сам писал выше, что класс парсер возвращает запрос с подстановленными значениями?
или я уже запутался.
ну, а какой fetch у инсерта с апдейтом? консинтентность возвращаемого значения должна ж быть, иначе это у вас не ООП, а другое слово)Да сорри, я там спросонок прогнал - не prepare(), a execute() возвращает буль вместо инстанса.
То есть, рвет цепочку prepare(query)->execute(data)->fetch() ровно посередине.
[result: true] ?Фанат,
ну, а какой fetch у инсерта с апдейтом? консинтентность возвращаемого значения должна ж быть, иначе это у вас не ООП, а другое слово)
да просто чтобы не плодить несколько классов результата, один вполне может обслуживать все ситуации - он же будет маленькийА смысл, если интерфейсы разные?
это разные слои, когда парсер и компилятор отделены - AR от фреймворка по выбору прикручивается за день что я и хочу сделать!для более опытных скорее всего, твой вариант будет ненужным ограничением функционала. Либо пишешь ПДОплюсь и все тебя поливают говном за поддержку / отсутствие подержки AR / дегидрации моделей / лезилоада / еще чего-то %)
не-не, здесь речь не об обязательности, а о возможности. Я же не предлагаю писать fetch() для инсертов. Я сожалею о том, что нельзя пользоваться method chaining в принципе.ну, а какой fetch у инсерта с апдейтом? консинтентность возвращаемого значения должна ж быть, иначе это у вас не ООП, а другое слово)
А можешь привести пример, где это нужно?это разные слои, когда парсер и компилятор отделены - AR от фреймворка по выбору прикручивается за день что я и хочу сделать!
хорошего слоя обработки типизированных плейсхолдеров с типами для названий таблиц нет нигде
SELECT * FROM `{$this->table}` ...