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,
>
> it's not really a new
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
parame
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 06/12/16 16:30, Adam Barat
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/
>> archives/605-debugging-pdo-
>
> 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 be
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 Mon,
>
> 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 emulat
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 that. Why do you pri
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 directl
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, you
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 feedback from the original
>
> 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 correspon
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 e
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
---
>
> > My point is that you are adding 'testing tools' which are only any use
> > to test themselves and not the actual interface? It's creating
> > additional code that has nothing to do with testing that PDO is working
> > cleanly properly across all databases, especially if it does not expect
> >
> My point is that you are adding 'testing tools' which are only any use
> to test themselves and not the actual interface? It's creating
> additional code that has nothing to do with testing that PDO is working
> cleanly properly across all databases, especially if it does not expect
> a working c
On 26/10/16 16:56, Adam Baratz wrote:
>>
>> Since PDO is an interface to third party databases this seems totally
>> out of place in PHP. Prepared statements are a sensible mechanism for
>> for anyone wanting secure access to those database, so what is the point
>> of this code.
>
> I don't want t
>
> Since PDO is an interface to third party databases this seems totally
> out of place in PHP. Prepared statements are a sensible mechanism for
> for anyone wanting secure access to those database, so what is the point
> of this code.
I don't want to solve for database access. I want to create
On 24/10/16 21:16, Adam Baratz wrote:
>> I've created an RFC to make it easier to work with emulated prepared
>> > statements:
>> > https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
>> >
> Does anyone have feedback?
Since PDO is an interface to third party databases this seems to
>
> I've created an RFC to make it easier to work with emulated prepared
> statements:
> https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation
>
Does anyone have feedback?
27 matches
Mail list logo
