Разделение DBAL на два класса, Connection и Statement

[fixxxer]

Ну, да, PDO с типизированными плейсхолдерами и фасадом для однострочных типовых действий. Почему бы и нет?

 

[WMix]

Если уж на то пошло, то сам SafeMysql должен быть фабрикой-фасадом, с соединением с базой работает SafeMysqlConnection

это же вопрос предварительной настройки, а я так больше идею описывал. с другой стороны все должно остаться минималически, чтоб новички не парились создавая обьект. те добавить и о то что ты предлагаешь возможно

и да, это обертка на обертку ), но с типами )

а если добавить пару чичь в SafeMysqlResult, типа группировка полей связанных (join) табличек обратно в деревянную структуру, вообще няшка получиться

 

[Фанат]

И тут внезапно оказывается, что в итоге написали PDO

Собственно, этот топик как раз навеян именно такими мыслями - сделать ПДО с моими фирменными типизованным блекджеком и однострочными шлюхами.

Плюс исправить очевидные косяки ПДО - к примеру, адское поведение prepare(), которое возвращает не стейтмент, а буль. Тут явно ноги растут из неумения пользоваться исключениями. Ведь если исключений нет, то надо проверять результат работы функции рукаме. Но ведь есть же исключения! И можно спокойно делать метод-чайнинг.
А в итоге любое обращение п АДО растягивается минимум на два вызова.

 

[Фанат]

Беда только в том, что не хватает ума спроектировать с фасадами.
Несчастный парсер - и то не знаю, куда воткнуть

 

[Фанат]

Неважно какой запрос - в php копирование при изменении, "создаваться" будет только сам объект, а оверхед на создание объекта маленький.

Нене, я конкретно про строку SQL.
Вот именно, переданные в конструктор параметры не увеличат размер памяти, но созданная строка - увеличит.
поэтому и предлагаю генерить по запросу.

если компилятор совмещен с парсером - не сделать адаптеро-зависимую генерацию sql, я бы делал в отдельном классе,

Что ты называешь компилятором? Составитель запроса?
Так ты же вроде сам писал выше, что класс парсер возвращает запрос с подстановленными значениями?
или я уже запутался.

 

[WMix]

Беда только в том, что не хватает ума спроектировать с фасадами.

это названо фасадом

$db->getOne(...);

уже готово, хочешь поменять?

 

[fixxxer]

Беда только в том, что не хватает ума спроектировать с фасадами.
Несчастный парсер - и то не знаю, куда воткнуть

Делаешь примерно как в PDO, без фасада, потом пишешь фасад такой, чтобы было удобно.

 

[Фанат]

WMix, fixxxer, ага, примерно понял

 

[флоппик]

к примеру, адское поведение prepare(), которое возвращает не стейтмент, а буль. Тут явно ноги растут из неумения пользоваться исключениями.

я бы сказал, тут ноги в целом из пхп растут))

Но в целом, если идея "переписать ПДО, но с моими плюшками", то WMix прав, тебе это надо делать для себя, т.к. для новичков стейтменты будут сложными, а для более опытных скорее всего, твой вариант будет ненужным ограничением функционала. Либо пишешь ПДОплюсь и все тебя поливают говном за поддержку / отсутствие подержки AR / дегидрации моделей / лезилоада / еще чего-то %)

 

[fixxxer]

Ай, говном поливать будут что угодно в любом случае =)

 

[Фанат]

Да сорри, я там спросонок прогнал - не prepare(), a execute() возвращает буль вместо инстанса.
То есть, рвет цепочку prepare(query)->execute(data)->fetch() ровно посередине.

 

[grigori]

fixxxer, нене, NS же, PSR, SafeMysql\SafeMysql\Connection, SafeMysql\SafeMysql\Statement - и composer.json
я ж не писал имена классов, чтоб Фаната не пугать )))

рвет цепочку prepare(query)->execute(data)->fetch() ровно посередине.

+1, сволочи

 

[grigori]

Нене, я конкретно про строку SQL.
Вот именно, переданные в конструктор параметры не увеличат размер памяти, но созданная строка - увеличит.
поэтому и предлагаю генерить по запросу.

мне в голову приходит только случай
$stmt = $PDO->prepare($sql);
$MyCurl->setHandler($stmt)->processBigRemoteData();

Что ты называешь компилятором? Составитель запроса?
Так ты же вроде сам писал выше, что класс парсер возвращает запрос с подстановленными значениями?
или я уже запутался.

Ты сказал что тебе нужно чтобы запрос генерился или в виде чистого sql, или в виде выражения с нативными плейсхолдерами.
Это паттерн стратегия - по желанию выбирается класс из набора, который выполняет задачу или одним способом, или другим.
Парсер один, он всегда возвращает массив с разобранным запросом.
Компиляторов может быть несколько - один собирает sql с данными, другой - sql с нативными плейсхолдерами.
Компилятор возвращает объект запроса, во втором случае в нем будут параметры, в первом - нет, только строка sql.
Executor тоже один: если параметры есть - байндит.

 

[флоппик]

Фанат,

Да сорри, я там спросонок прогнал - не prepare(), a execute() возвращает буль вместо инстанса.
То есть, рвет цепочку prepare(query)->execute(data)->fetch() ровно посередине.

ну, а какой fetch у инсерта с апдейтом? консинтентность возвращаемого значения должна ж быть, иначе это у вас не ООП, а другое слово)

 

[grigori]

Фанат,

ну, а какой fetch у инсерта с апдейтом? консинтентность возвращаемого значения должна ж быть, иначе это у вас не ООП, а другое слово)

[result: true] ?
$Stmnt->getAffectedRows() ?

 

[fixxxer]

А смысл, если интерфейсы разные?

Хотя, с другой стороны, в случае с более базами данных insert/update ... returning никто не отменял, так что, может, и не разные.

 

[grigori]

А смысл, если интерфейсы разные?

да просто чтобы не плодить несколько классов результата, один вполне может обслуживать все ситуации - он же будет маленький

 

[grigori]

для более опытных скорее всего, твой вариант будет ненужным ограничением функционала. Либо пишешь ПДОплюсь и все тебя поливают говном за поддержку / отсутствие подержки AR / дегидрации моделей / лезилоада / еще чего-то %)

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

 

[Фанат]

ну, а какой fetch у инсерта с апдейтом? консинтентность возвращаемого значения должна ж быть, иначе это у вас не ООП, а другое слово)

не-не, здесь речь не об обязательности, а о возможности. Я же не предлагаю писать fetch() для инсертов. Я сожалею о том, что нельзя пользоваться method chaining в принципе.

 

[Фанат]

это разные слои, когда парсер и компилятор отделены - AR от фреймворка по выбору прикручивается за день что я и хочу сделать!
хорошего слоя обработки типизированных плейсхолдеров с типами для названий таблиц нет нигде

А можешь привести пример, где это нужно?
Мне казалось, что во всех AR тупо пишется

SELECT * FROM `{$this->table}` ...

и этого, в общем, достаточно. Не?