Hi,
I'd like to add a new method that would return the prepared statement as it
was executed. It's common for people I work with to want this info for
debugging, but you can't get it from userland. The functionality is similar
to, but distinct from PDOStatement::debugDumpParams().
I figure it's always easier to discuss proposals alongside real code:
https://github.com/php/php-src/pull/2159
Please let me know what you think, if an RFC would be appropriate, or what.
Thanks,
Adam
Hi,
I'd like to add a new method that would return the prepared statement as it
was executed. It's common for people I work with to want this info for
debugging, but you can't get it from userland. The functionality is similar
to, but distinct from PDOStatement::debugDumpParams().I figure it's always easier to discuss proposals alongside real code:
https://github.com/php/php-src/pull/2159Please let me know what you think, if an RFC would be appropriate, or what.
To be perfectly honest, my wish is that EMULATE_PREPARES could be
deprecated and removed and I see something this as a step in the
opposite direction.
That said, I think a tiny RFC that explains what's the problem you are
trying to solve, the current issue and possible other solutions would be
very welcome. This is an API change and most likely will require all the
drivers to be adapted.
Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/
I really doubt this method will prove useful in practice for the use case
you mention, and for a number of a reasons.
- The name is misleading (there is no real query string in the case of
native prepared statements - the SQL and data are always separate) - You would have to execute the statement first in order to get the debug
information you're looking for (meaning that if the execution of the
statement fails for any reason other than what the SQL parser can detect,
there is no useful debug information from this method) - This only works if you use emulated prepares, which creates a whole new
stream of complaints by people who don't understand the difference
I don't think the real problem is seeing the entire query assembled with
the parameters filled in, because the buggy part would never be the actual
parameter values themselves. If there is a bug in the SQL, it's typically
the result of a syntax error, or constraint violation, or name error. I
sincerely doubt this method would prove useful in debugging in any of those
things. The server-side error messages from the DBMS would prove more
useful in those cases.
In other words, I believe people would get more useful debug information by
just turning off emulated prepares, putting PDO into Exception error mode,
and looking at the error information provided by the DBMS since with
server-side prepares you get failure upon preparing, and before execution
even begins, such that parameters are no longer the actual concern for
error.
Hi,
I'd like to add a new method that would return the prepared statement as
it
was executed. It's common for people I work with to want this info for
debugging, but you can't get it from userland. The functionality is
similar
to, but distinct from PDOStatement::debugDumpParams().I figure it's always easier to discuss proposals alongside real code:
https://github.com/php/php-src/pull/2159Please let me know what you think, if an RFC would be appropriate, or
what.To be perfectly honest, my wish is that EMULATE_PREPARES could be
deprecated and removed and I see something this as a step in the
opposite direction.That said, I think a tiny RFC that explains what's the problem you are
trying to solve, the current issue and possible other solutions would be
very welcome. This is an API change and most likely will require all the
drivers to be adapted.Cheers
Matteo Beccati
Development & Consulting - http://www.beccati.com/