Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?
For now my code works around this design decision, but not everybody
is cognizant of this behavior.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
- szept. 3. 6:14 ezt írta ("Scott Arciszewski" scott@paragonie.com):
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For now my code works around this design decision, but not everybody
is cognizant of this behavior.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com--
Last time we discussed this it was Anthony who proposed the change and
Rasmus shed some light on why did we have the emulation in the first place.
We can have change the default but we should have an RFC clearly stating
the impact (an additional network roundtrip and the native prepares being
less flexible vs. better security and performance gain in case of executing
the same prepared query multiple times)
- szept. 3. 6:14 ezt írta ("Scott Arciszewski" scott@paragonie.com):
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For now my code works around this design decision, but not everybody
is cognizant of this behavior.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com--
Last time we discussed this it was Anthony who proposed the change and
Rasmus shed some light on why did we have the emulation in the first place.
We can have change the default but we should have an RFC clearly stating the
impact (an additional network roundtrip and the native prepares being less
flexible vs. better security and performance gain in case of executing the
same prepared query multiple times)
Sure, and I'm fine with this being a 7.1 thing since most people work
around this anyway.
But I would like it to be changed eventually, however.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
- szept. 3. 6:14 ezt írta ("Scott Arciszewski" scott@paragonie.com):
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For now my code works around this design decision, but not everybody
is cognizant of this behavior.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com--
Last time we discussed this it was Anthony who proposed the change and
Rasmus shed some light on why did we have the emulation in the first place.
We can have change the default but we should have an RFC clearly stating
the impact (an additional network roundtrip and the native prepares being
less flexible vs. better security and performance gain in case of executing
the same prepared query multiple times)
for the record, here is the last discussion on the topic:
http://grokbase.com/t/php/php-internals/126fcmvv04/patch-pr-disable-attr-emulate-prepares-by-default-for-pdo-mysql
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Last time we discussed this it was Anthony who proposed the change and
Rasmus shed some light on why did we have the emulation in the first place.
We can have change the default but we should have an RFC clearly stating
the impact (an additional network roundtrip and the native prepares being
less flexible vs. better security and performance gain in case of executing
the same prepared query multiple times)for the record, here is the last discussion on the topic:
http://grokbase.com/t/php/php-internals/126fcmvv04/patch-pr-disable-attr-emulate-prepares-by-default-for-pdo-mysql
And the information on just how each database handles the various
abstractions of place holders is still missing. While the current
proposal is framed as only effecting the pdo_mysql driver, if the
default way this is handled then affects what IS currently working
cross-database then it does have a much wider impact?
That PDO is simply not up to the job it was originally pushed to provide
is a fact and making it work just for one database begs the question
"why keep it". Testing with a generic set of code should work
identically across all supported databases and that does mean that some
level of emulation is required but currently there is no documentation
on just what does and what does not work.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Scott
2015-09-03 6:14 GMT+02:00 Scott Arciszewski scott@paragonie.com:
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?
For 7.0, it is a no-go, and for the 7.0.x releases, I'm not so keen on
(and I'm sure Anatol can back me up on this) to introduce such a
change in behaviour in a patch release, so please target 7.1 with your
future RFC.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi Scott
2015-09-03 6:14 GMT+02:00 Scott Arciszewski scott@paragonie.com:
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For 7.0, it is a no-go, and for the 7.0.x releases, I'm not so keen on
(and I'm sure Anatol can back me up on this) to introduce such a
change in behaviour in a patch release, so please target 7.1 with your
future RFC.--
regards,Kalle Sommer Nielsen
kalle@php.net
Okay, no complaint here. I just didn't know if the RM would be open to
the possibility of changing the default value in 7 (since it's a major
version change and people expect things to break).
Targeting 7.1 is fair; I'll open an RFC once I'm done with my
immediate responsibilities. :)
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
Hi Scott,
Scott Arciszewski wrote:
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For now my code works around this design decision, but not everybody
is cognizant of this behavior.
I don't know if there's really still time to add this in PHP 7.0, but I
think emulated prepares being switched off would be a good idea. One
reason in particular is that this means we'd get properly typed results,
rather than just strings, which would work better with PHP 7's new
scalar type hints. PDO returning strings everywhere when using emulation
was one thing I was completely unaware of until I turned on strict typing.
Cheers.
Andrea Faulds
http://ajf.me/
Hi Scott,
Scott Arciszewski wrote:
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For now my code works around this design decision, but not everybody
is cognizant of this behavior.I don't know if there's really still time to add this in PHP 7.0, but I
think emulated prepares being switched off would be a good idea. One
Good enough to take the performance hit by the extra roundtrip?
reason in particular is that this means we'd get properly typed results,
rather than just strings, which would work better with PHP 7's new
scalar type hints. PDO returning strings everywhere when using emulation
was one thing I was completely unaware of until I turned on strict typing.
For some definition of "properly". Large integers might still become
strings, same for decimals etc. Also if you might use other databases
than MySQL still anything might happen.
Also mind that there are subtle differences on what can be done. A bit
constructed example but in MySQL you can't prepare
CREATE TABLE foo (id INT DEFAULT ?)
while PDO would let you do this.
johannes
On Mon, Sep 7, 2015 at 1:23 AM, Johannes Schlüter johannes@schlueters.de
wrote:
Hi Scott,
Scott Arciszewski wrote:
Inspired by http://stackoverflow.com/a/12202218/2224584
Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
statements off by default, and still allow developers to turn it on if
they really want them?For now my code works around this design decision, but not everybody
is cognizant of this behavior.I don't know if there's really still time to add this in PHP 7.0, but I
think emulated prepares being switched off would be a good idea. OneGood enough to take the performance hit by the extra roundtrip?
reason in particular is that this means we'd get properly typed results,
rather than just strings, which would work better with PHP 7's new
scalar type hints. PDO returning strings everywhere when using emulation
was one thing I was completely unaware of until I turned on strict
typing.For some definition of "properly". Large integers might still become
strings, same for decimals etc. Also if you might use other databases
than MySQL still anything might happen.Also mind that there are subtle differences on what can be done. A bit
constructed example but in MySQL you can't prepare
CREATE TABLE foo (id INT DEFAULT ?)
while PDO would let you do this.johannes
also, binding ASC/DESC for ORDER BY is a common gotcha when moving from
emulated prepares to native.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu