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

[grigori]

в AR ты имя таблицы в запрос не пишешь, каждый класс AR привязан к таблице, и руками пишутся связи,
попробуй на AR указать связь с нужной таблицей в join по типу параметра в зависимости от выбранного фильтра в каталоге.
производители - в одной таблице, цвет - в другой, и ... $Product->with($param_type) - вот и кастомный плейсхолдер.

 

[Фанат]

производители - в одной таблице, цвет - в другой, и как ты ... $Product->with($param_type) - вот и кастомный плейсхолдер.

Логично. Тут еще именованные бы отлично подошли

 

[grigori]

когда ты сделаешь, можно будет дописать кастомный плейсхолдер для datetime, чтобы передавать в любом формате, например, timestamp в int, а компилятор форматирует в DATE_W3C
постоянно надо писать это приведение

 

[флоппик]

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

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

Понятно, что я бы тоже возвращал обратно какой-то resulting object с фетчем для селектов и т.п., я просто говорю почему у пдо - консистентное поведение в этом месте.

 

[Фанат]

Понятно, что я бы тоже возвращал обратно какой-то resulting object с фетчем для селектов

Да нет же в ПДО никакого специального resulting object-а для селектов! Есть один и тот же стейтмент.

$stmt = $pdo->prepare($sql);
$stmt->execute($params); // здесь мы меняем состояние $stmt но возвращаем буль!
$data = $stmt->fetch();

Для инсерта все будет то же самое, только без последней строчки.
Суть в том, что $stmt все равно один и тот же. Я не вижу оправданий тому, чтобы execute возвращал буль а не стейтмент и не считаю такое поведение консистентным.

Собственно, переопределив класс PDOstatement эту проблему можно решить:

class myPDOStatement extends PDOStatement
{
    function execute($data = array())
    {
        parent::execute($data);
        return $this;
    }
}

- и никаких проблем это не создаёт, ни с инсертами, ни с апдейтами.

 

[grigori]

правда, не будет работать на persistent

 

[Вурдалак]

Фанат, ты что-нибудь слышал про Liskov Substitution Principle?

P.S.

 

[флоппик]

Да нет же в ПДО никакого специального resulting object-а для селектов!

Ну так и я не его автор. Я же сказал, как бы сделал _я_, а не авторы пдо.

Ну как бы да, как Вурдалак написал, SOLID ломается. Это не тру-ООП.

правда, не будет работать на persistent

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

 

[grigori]

логично - если на сервере ресурс остается выделенным, а клиент о нем не знает, это плохо, но как это связано с расширением класса - непонятно

 

[Фанат]

Ну так надо дергать mysql_change_user(), как это делает mysqli.
Тогда ничего на сервере не останется выделенным - ни транзакции, ни препареды, ни переменные

 

[флоппик]

Ну так надо дергать mysql_change_user(), как это делает mysqli.
Тогда ничего на сервере не останется выделенным - ни транзакции, ни препареды, ни переменные

Да, да. Просто нужно понимать, что ПХП - это единственный язык, который считает такое поведение правильным.

логично - если на сервере ресурс остается выделенным, а клиент о нем не знает, это плохо, но как это связано с расширением класса - непонятно

Не, в стандартый PDOStatement восстановить можно, что и происходит в случае персистентого соединения в ПДО — даже если задать пользовательский класс для стейтмента, вернется все равно PDOStatement. Т.к. унаследованный пользовательский стейтмент может что-то перекрыть в реализации, иметь дополнительные поля, и ты не можешь восстановить его однозначно обратно. (не храня где-то эту доп инфу, что не обязанность пдо, и тд, и тп...)
Что-то в этом духе.

 

[grigori]

я запутался - как это при персистентном pdo восстанавливаются объекты PDOStatement из старой сессии, нахрена ж они сдались в новой?

 

[флоппик]

я запутался - как это при персистентном pdo восстанавливаются объекты PDOStatement из старой сессии, нахрена ж они сдались в новой?

Нет гарантии, что пользовательский класс стейтмента будет доступен в следующем вызове, а значит, нельзя гарантированно восстановить обьект ПДО для переиспользования подключения.
http://grokbase.com/t/php/pecl-dev/0654fyqbvz/pdo-custom-class-for-statement

 

[AnrDaemon]

Начните разговор с того, что вы вообще не знаете, будет ли когда-то этот следующий вызов. И знать этого не можете. В принципе.

 

[Фанат]

Начните разговор с того, что вы вообще не знаете, будет ли когда-то этот следующий вызов. И знать этого не можете. В принципе.

А какое это имеет значение?

 

[Фанат]

Нет гарантии, что пользовательский класс стейтмента будет доступен в следующем вызове, а значит, нельзя гарантированно восстановить обьект ПДО для переиспользования подключения.
http://grokbase.com/t/php/pecl-dev/0654fyqbvz/pdo-custom-class-for-statement

Что-то я не понял.
Я всегда считал, что "где-то там" хранится хендлер соединения, ничего общего с конкретным драйвером не имеющий. Получается - это не так?
А вот, кстати, интересно - можно ли скрестить ежа с ужом? В смысле создать постоянное соединение в mysqli и потом подцепить его в ПДО?

 

[флоппик]

Что-то я не понял.
Я всегда считал, что "где-то там" хранится хендлер соединения, ничего общего с конкретным драйвером не имеющий. Получается - это не так?

У хендлера соединения-то много всякого, я так понимаю, там и атрибуты соединения, установленные кодировки, сертификаты, если там ссл соединение, и всю эту фигню ты должен получать взад через всякие mysqli_get_charset, getAttribute... и тп.

 

[grigori]

Нет гарантии, что пользовательский класс стейтмента будет доступен в следующем вызове, а значит, нельзя гарантированно восстановить обьект ПДО для переиспользования подключения.
http://grokbase.com/t/php/pecl-dev/0654fyqbvz/pdo-custom-class-for-statement

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

This can be fixed, it just hasn't happened yet. In the meantime, we don't let you do it.
--Wez.

создать постоянное соединение в mysqli и потом подцепить его в ПДО?

только на уровне кастомного экстеншена

 

[Фанат]

This can be fixed, it just hasn't happened yet. In the meantime, we don't let you do it.
--Wez.

Прошло 9 лет.... А Wes и ныне там.

 

[флоппик]

grigori, я и не говорил, что это поведение логичное или правильное, или что его нельзя реализовать. Я просто сказал, что сейчас сделано так, как сделано.