Everything

php

[RFC] Debugging PDO Prepared Statement Emulation

php.internals

Adam Baratz

9 years ago

Hi,

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

Based on feedback from a previous thread[1], I added some context and added
two other potential solutions to the problem. Please share your feedback.
I'd like to hone in on one solution for the eventual vote.

Thanks,
Adam

---
[1] http://marc.info/?l=php-internals&m=147638162506291&w=2

Adam Baratz

9 years ago

>
> 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?

Lester Caine

9 years ago

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 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. The emulated versions simply replace parameters with raw
data so database engines that don't have parameters get simple SQL
statements which can be directly viewed. You do not need any code to
create virtual parameters that are useless in the wire connection to the
database anyway.

Older mysql did not have prepared queries hence the default of
converting the more secure SQL into something old mysql could handle. I
presume that dblib has the same fundamental problem? But mssql has
prepared statements so dblib SHOULD provide that interface?

--
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

Adam Baratz

9 years ago

>
> 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 a testing tool
for emulated prepared statements. We already have
PDOStatement::debugDumpParams() for revealing some PDO internals. This
would offer another slice. I don't want to create another path for talking
to the database.

I updated the RFC introduction to make this clearer. I also added a
description of another use case (.phpt tests).

Older mysql did not have prepared queries hence the default of

> converting the more secure SQL into something old mysql could handle. I
> presume that dblib has the same fundamental problem? But mssql has
> prepared statements so dblib SHOULD provide that interface?
>

MSSQL understands prepared statements, but not through DB-Library. The API
dates back to the early '80s. It's really quite primitive. ODBC is the
"right" way to use prepared statements with MSSQL, but it's honestly not a
drop-in replacement.

Lester Caine

9 years ago

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 to solve for database access. I want to create a testing tool
> for emulated prepared statements. We already have
> PDOStatement::debugDumpParams() for revealing some PDO internals. This
> would offer another slice. I don't want to create another path for talking
> to the database.
>
> I updated the RFC introduction to make this clearer. I also added a
> description of another use case (.phpt tests).

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 connection to carry out the testing.

> Older mysql did not have prepared queries hence the default of
>> converting the more secure SQL into something old mysql could handle. I
>> presume that dblib has the same fundamental problem? But mssql has
>> prepared statements so dblib SHOULD provide that interface?
>
> MSSQL understands prepared statements, but not through DB-Library. The API
> dates back to the early '80s. It's really quite primitive. ODBC is the
> "right" way to use prepared statements with MSSQL, but it's honestly not a
> drop-in replacement.

That has been the whole problem with PDO all along. It's not simply a
'drop in' replacement in a lot of places and it should either be fixed
or retired. DB-Library should simply handle prepared statements by
converting them into simple SQL that the API CAN handle. That is the
point of 'emulation' and it should not need any additional tools to
debug it. The .phpt tests should be testing that the emulated SQL is
producing the right results AFTER processing over the interface.

--
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

Adam Baratz

9 years ago

> 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 connection to carry out the testing.

The SQL parser is shared between drivers, so in a sense it's part of
the interface. It's already possible to test the interface by
observing the effects of queries. This would allow testing of what
happens immediately prior. The parser alone is over 700 LoC.

Adam Baratz

9 years ago

>
> > 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 connection to carry out the testing.
>
> The SQL parser is shared between drivers, so in a sense it's part of
> the interface. It's already possible to test the interface by
> observing the effects of queries. This would allow testing of what
> happens immediately prior. The parser alone is over 700 LoC.
>

I incorporated some feedback from this thread and reduced the RFC to a
single proposal:
https://wiki.php.net/rfc/debugging_pdo_prepared_statement_emulation

Matteo Beccati

9 years ago

Hi Adam,

On 17/10/2016 21:28, Adam Baratz wrote:

> Hi,
>
> 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
>
> Based on feedback from a previous thread[1], I added some context and added
> two other potential solutions to the problem. Please share your feedback.
> I'd like to hone in on one solution for the eventual vote.

There's value in improving tests for emulated prepares, but as I stated
somewhere else, I would rather see them deprecated and removed rather
than encouraged.

Besides, I gather that FreeTDS also supports them since quite a long
time, so I don't see why pdo_dblib should exclusively use and promote
usage of emulated prepares.


Cheers

--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Adam Baratz

9 years ago

>
> There's value in improving tests for emulated prepares, but as I stated
> somewhere else, I would rather see them deprecated and removed rather
> than encouraged.
>

I left a note about this in the "Future Scope" section[1]. If we deprecate
emulated prepares, it would make sense to deprecate
PDOStatement::activeQueryString()
at the same time, since their utility is intertwined. But as long as
pdo_dblib is supported, the possibility of deprecating emulated prepares
shouldn't get in the way of being able to support it.

I thought about having PDOStatement::activeQueryString() trigger an error
and/or return false if emulated prepares aren't enabled. This would make
the usage clearer, but I thought it would be best to limit the side effects
of a debug tool.

Besides, I gather that FreeTDS also supports them since quite a long

> time, so I don't see why pdo_dblib should exclusively use and promote
> usage of emulated prepares.
>

FreeTDS supports them, but not through the DB-Library API. The other
APIs[2] implemented by FreeTDS support prepared statements.

---
[1] https://wiki.php.net/rfc/debugging_pdo_prepared_
statement_emulation#future_scope
[2] http://www.freetds.org/which_api.html