Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99116
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <000601d2cff3$bbffc5f0$33ff51d0$@marcodor.com>
References: <CADxrgCN5Y5dieZEoP2bfM7fSD5UpUt4s6oVNT95etE-VDsQpbw@mail.gmail.com>
 <000601d2cff3$bbffc5f0$33ff51d0$@marcodor.com>
Date: Fri, 19 May 2017 12:25:34 +0200
Message-ID: <CADxrgCNChrCSAeAmnM_iQ=q6BR_CBO8z6Q5E1f17qUwXDBf1oQ@mail.gmail.com>
To: Dorin Marcoci <dorin.marcoci@marcodor.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a1146cc101926b6054fddf13f"
Subject: Re: PDO Parameter types // PDO::PARAM_AUTO
From: adambaratz@php.net (Adam Baratz)

--001a1146cc101926b6054fddf13f
Content-Type: text/plain; charset="UTF-8"

>
> > The risk with this is queries could lose portability between drivers.
> There are differences in the level of information each one can get from the
> DB server, and different costs associated with asking.
> > I think the right model is to have PDO types map directly to SQL types.
> That said, the code and documentation don't take a strong stance on how
> types should work. And there's not a lot of agreement in the community, at
> least as indicated by discussions on this list.
>
> Yes, agree about portability. But from other side, it will be a great
> benefit for drivers that supports server side prepares, not just emulation.
>
> Maybe even a better way is just to change default param type from
> PARAM_STR to PARAM_AUTO in bindValue family routines, without any driver
> options or configs.
> So if drivers supports server prepares with type hinting, OK: treat it
> better, if not, push it as a string like is now.
> Anyway, there is not a documented standard what driver should do when you
> pass something like bindValue('param', '', PDO::PARAM_BOOL) or
> bindValue('param', 't', PDO::PARAM_BOOL) or bindValue('param', '0',
> PDO::PARAM_BOOL)
> In case if data type is specified, then force it, as dictate the php code.
>
> What do you think?
>

I'm not sure that changes the proposal too much. My position is still that
I'd like PDO to be less "magical," to put more of the burden on providing
the right content to the user. Much of PHP internals are about providing a
light layer on a third-party library (in this case, all the DB libraries).
You can then compose them as needed to get the right functionality for your
application. We get a lot of power and flexibility from that. Making APIs
that are too "opinionated" makes it harder for users to control their
destiny.

I haven't tested this, but I think you could implement the functionality
you need in userland. You could write a class like this:

class MyPDOStatement extends \PDOStatement {
  public function bindValue($parameter, $value, $data_type = -1) { // or
define a const somewhere for an AUTO type
    if ($data_type == -1) {
      switch (gettype($value) {
        case 'boolean':
          $data_type = \PDO::PARAM_BOOL;
          break;
        default:
          $data_type = \PDO::PARAM_STR;
          break;
      }
      // and add any other cases you care about
    }
    return parent::bindValue($parameter, $value, $data_type);
  }
}

Then when you construct a new \PDO instance, set a
\PDO::ATTR_STATEMENT_CLASS option referring to that class. There are some
examples in ext/pdo/tests, or you can look at the implementation of
\PDO::prepare() for the nitty gritty.

I think this hook is a good example of the principle I was describing. PDO
may only have a basic set of tools, but it makes it easy to extend
according to your preferences.

Hope this helps,
Adam

--001a1146cc101926b6054fddf13f--