Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96617
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 185.153.204.214 cause and error)
To: internals@lists.php.net
References: <CADxrgCNboXRbZf1V7RWtGBvbbYA-h8bknu=YD8dQ0jjUtKYtbw@mail.gmail.com>
 <CADxrgCNN4=xRUsX2mOMOCDi6GcZSqHCMZEQpkNV9T9fFpNaJfw@mail.gmail.com>
 <cc2d7ef8-5058-bd5d-91d1-117f11c1f056@lsces.co.uk>
 <CADxrgCPf-bVfLfcEv-v9p3L8wAMt8+oHVMCYXsJHh+-Z47fumA@mail.gmail.com>
Message-ID: <12f56cf0-e3c1-9df3-c834-18246286524a@lsces.co.uk>
Date: Wed, 26 Oct 2016 17:30:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CADxrgCPf-bVfLfcEv-v9p3L8wAMt8+oHVMCYXsJHh+-Z47fumA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation
From: lester@lsces.co.uk (Lester Caine)

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