Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96347
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9987c0a5-2315-0a8c-0f96-7a45323fa86d@beccati.com>
References: <CADxrgCN4GKji5dx=cuCfyU33bzUH9ziG8c7B71e5T0-jFXNjXQ@mail.gmail.com>
 <9987c0a5-2315-0a8c-0f96-7a45323fa86d@beccati.com>
Date: Thu, 13 Oct 2016 15:12:42 -0400
Message-ID: <CAL+t6cG5+hYhr+H29TJ=wGrjg8-LG8oW25jp30XVsXfSjswjkQ@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Adam Baratz <adambaratz@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114b2ffae10403053ec3e4d9
Subject: Re: [PHP-DEV] PDOStatement::activeQueryString()
From: theanomaly.is@gmail.com (Sherif Ramadan)

--001a114b2ffae10403053ec3e4d9
Content-Type: text/plain; charset=UTF-8

I really doubt this method will prove useful in practice for the use case
you mention, and for a number of a reasons.

1) The name is misleading (there is no real query string in the case of
native prepared statements - the SQL and data are always separate)
2) 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)
3) 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.

On Thu, Oct 13, 2016 at 2:42 PM, Matteo Beccati <php@beccati.com> wrote:

> Hi,
>
> On 13/10/2016 19:59, Adam Baratz wrote:
> > 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.
>
> 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/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a114b2ffae10403053ec3e4d9--