Who is the architector/staff board of PDO?
PDO is maintained with the rest of PHP core, so it follows the same process
outlined in CONTRIBUTING.md. That is to say, there's no central governance.
Some people, as listed in EXTENSIONS, have appropriate karma and handle
maintenance that falls outside of the contribution guide.
That's why I think, it will be great to have a special type like
PDO::PARAM_AUTO and a config flag to set it as default instead of
PARAM_STR.
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.
I agree with Matteo that param hooks might provide a better solution to the
specific problem you're describing.
Thanks,
Adam
Hi Adam,
From: Adam Baratz [mailto:adambaratz@php.net]
Sent: Thursday, May 18, 2017 3:23 PM
That's why I think, it will be great to have a special type like
PDO::PARAM_AUTO and a config flag to set it as default instead of PARAM_STR.
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 agree with Matteo that param hooks might provide a better solution to the specific problem you're describing.
I'm using this way, just now. But I don’t like the way that code
->BindValue('bool_param', false);
give me internally in C driver code a string type ZVAL with an empty value in it, ie transform it to a string ZVAL because of default string type.
Yep, forcing it to be boolean like ->BindValue('bool_param', false, PDO::PARAM_BOOL); works.
Just I want do not care at all about param data types as driver know expected types better than me.
D.
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
Hi Adam,
From: Adam Baratz [mailto:adambaratz@php.net]
Sent: Friday, May 19, 2017 1:26 PM
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.
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;
Hello Adam,
From: Adam Baratz [mailto:adambaratz@php.net]
Sent: Friday, May 19, 2017 1:26 PM
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.
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.
Do you think by replacing default PARAM_STR with PARAM_AUTO will do a lot of magic?, it seems really minor or nothing at all
It will just prevent casting ZVAL internally to a string ZVAL for a few drivers that supports server side prepares.
Each PDO driver will have a static bool property that will control this behavior with defaults as it works now.
It should not break any portability across drivers, especially when this data type is explicitly specified.
Can you find a sample where this change will have some impact?
How "your" driver works when you do bindValue('param', false) and expected field type on the server is a boolean?
I think server side prepares are a really good feature that we should take into account for servers providing this, not just by cutting features because of some that do not support it.
ps. Sorry for previous message, sent by mistake, anyone could delete it?
D.