Morning,
Can you please update the RFC with the dates that voting started and will
end, so that anyone browsing knows when the deadline for decision is
without trawling through internals.
Cheers
Joe
On Fri, Dec 9, 2016 at 9:36 AM, Matteo Beccati wrote:
> Hi Guilherme,
>
>
Hi Guilherme,
it's not really a new method. Just some more output to the existing
debugDumpParams method, which is indeed available after execute() when
emulated prepares is supported by the driver and currently active. The
method output already depends on its location: before/after binding
Hi Adam,
Providing my input on why I voted "NO".
Your proposed new method is not pure. This means it does have distinct
responses depending on where it's located in the code.
That's a big no-no for me.
Cheers,
On Tue, Dec 6, 2016 at 12:15 PM, Lester Caine wrote:
> On
On 06/12/16 16:30, Adam Baratz wrote:
>> This issue is not difficult to solve in userland, at least well enough for
>> debugging in my experience. Here's an older example I wrote up on my blog
>> that worked (but I'm told is broken right now): https://daveyshafik.com/
>>
>
> This issue is not difficult to solve in userland, at least well enough for
> debugging in my experience. Here's an older example I wrote up on my blog
> that worked (but I'm told is broken right now): https://daveyshafik.com/
> archives/605-debugging-pdo-prepared-statements.html
>
I want to
This issue is not difficult to solve in userland, at least well enough for
debugging in my experience. Here's an older example I wrote up on my blog
that worked (but I'm told is broken right now):
https://daveyshafik.com/archives/605-debugging-pdo-prepared-statements.html
Thanks,
- Davey
On
>
> Could you please explain what's the use case? As far as I'm concerned
>> such information would only be useful during PDO driver development,
>> phpt files and bug reporting / fixing.
>>
>
> It's pretty simple : debugging and optimizing scripts and statements. I've
> lost hours, manually
Le Fri, 02 Dec 2016 14:54:04 +0100, Matteo Beccati a
écrit:
On 02/12/2016 08:36, Thomas Nunninger wrote:
Hi,
So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T
I second
Hi,
On 01/12/2016 18:38, Adam Baratz wrote:
>>
>> I'll incorporate it, and the content of this subthread, in the RFC when I
>> get my next free five minutes. :)
>>
>
> Done. And because of the scope of the v2 implementation, I changed the
> target release to next 7.1.x.
Could you please revert?
>
> Could you please revert? Albeit minor, it's a new feature and therefore
> it belongs to 7.2.
No problem. Reverted.
Hi,
On 02/12/2016 15:20, Thomas Nunninger wrote:
>> Could you please explain what's the use case? As far as I'm concerned
>> such information would only be useful during PDO driver development,
>> phpt files and bug reporting / fixing.
>
> Sometimes I'd like to log what SQL is really used that I
Hi,
On 12/02/2016 02:54 PM, Matteo Beccati wrote:
On 02/12/2016 08:36, Thomas Nunninger wrote:
Hi,
So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T
I second that. Why do you print it
On 02/12/2016 08:36, Thomas Nunninger wrote:
> Hi,
>
>> So, if I only want to get the emulated prepared statement, I have to do
>> ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
>> back T_T
>
> I second that. Why do you print it directly? Wouldn't it be better to
> return a
Hi,
So, if I only want to get the emulated prepared statement, I have to do
ob_start()/ob_get_clean(), then use a regexp to fetch it ? I want v1
back T_T
I second that. Why do you print it directly? Wouldn't it be better to
return a structured array with the information needed? If needed,
Le Thu, 17 Nov 2016 23:19:38 +0100, Adam Baratz a
écrit:
Hi,
Based on my second thoughts on my initial approach, I created an RFC to
supplant it:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2
I believe this better addresses the negative
>
> I'll incorporate it, and the content of this subthread, in the RFC when I
> get my next free five minutes. :)
>
Done. And because of the scope of the v2 implementation, I changed the
target release to next 7.1.x.
Thanks,
Adam
Hi,
> Basically, you'd never see this kind of example:
> >
> > SQL: "SELECT * FROM tbl WHERE x = ?"
> >> Sent SQL: "SELECT * FROM tbl WHERE x = $1"
> >>
>
> why not? That's what active_query_string contains e.g. in pdo_pgsql w/o
> emulate prepares. Which is more or less what has been sent to the
Hi Adam,
On 29/11/2016 00:16, Adam Baratz wrote:
> I'd be happy to make the feature more specific. The "Parsed" line would
> only show with emulated prepares enabled, after execute() has been called.
> I'd prefer using "Parsed" because the language would be more specific. It
> would also
Hi,
I would not use "Parsed SQL" though, as it's not just the result of
> parsing. In fact it could effectively be what has been sent to the backend,
> regardless of statement emulation...
>
I'd be happy to make the feature more specific. The "Parsed" line would
only show with emulated prepares
Hi Adam,
On 28/11/2016 16:29, Adam Baratz wrote:
>> Based on my second thoughts on my initial approach, I created an RFC to
>> supplant it:
>> https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2
>>
>
> I'd appreciate any feedback on this RFC, especially from any of the people
Hi,
> Based on my second thoughts on my initial approach, I created an RFC to
> supplant it:
> https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation_v2
>
I'd appreciate any feedback on this RFC, especially from any of the people
who voted against the original[1].
Thanks,
Adam
21 matches
Mail list logo