Re: [PDO] wiki clean up and potential in person meeting

Lester Caine wrote:
> Wez - the current discussion is about what NEEDS DOING ... and it is 
> the DATA abstraction that is not consistent - which is why 
> applications that have been converted to PDO are now hitting the brick 
> wall since most 'conversions' are only MySQL compliant. Adding 
> posgresql is not difficult, but is a lot of additional hand coding, 
> duplicating large blocks of code that work with Postgresql rather than 
> MySQL. THEN switching to include Oracle and the others falls over 
> because the data is not simply matched, such as where CLOB replaces 
> TEXT fields. The main question that was asked is if PDO can replace 
> the generic drivers. Currently the answer is no, and so that fact 
> should be made clear. PDO is NOT providing even data abstraction. 
> Simply a crude set of compatible functions that can't CURRENTLY be 
> combined with the more advanced transaction and other features of the 
> generic drivers.
>
> I have been asking for HELP to address the CLOB problem and solve the 
> problem across all drivers, but without any replies ..... I WOULD like 
> to help with PDO, but in the absence of any progress at all I can't 
> see anything to gain from doing so? In the meantime, I will continue 
> to support Oracle and Firebird via ADOdb 'reconversions'. At least 
> that works out of the box ..... we have several projects each writing 
> their own 'compatibility' layer on top of PDO - which is rather a 
> waste of resources! Especially when it only results in compatibility 
> with a couple of databases.
Hi

Well, I agree that that even for simple data the whole parameter 
handling is broken.

I think I remember right you want all data to be received / send as 
string if PDO sees a clob or blob as field?

While I haven't explicit written this on the brainstorming wiki page I 
thought it would be clear that I proposed to handle (B|C)LOBS always as 
string on the binding site (convert_to_string) regardless of input or 
output, while allowing to have streams optional
On the other site, the driver needs to transport the data into the blob. 
This won't be easy, maybe even impossible on the driver site, but until 
now there was zero reaction for the things I have written on the wiki 
page. :(

A lot of features I would like aren't on the list neither on the wiki 
page because simply I need the backward compatibility with old php 
versions and as far as I can tell there won't be any feature additions 
on the old 5.2 tree neither BC breaks are tolerable. So my goal wasn't a 
database abstraction layer but a working base PDO.

I still think the whole data flow between user-code, PDO and PDO Drivers 
have to be defined now and not later, but without input from driver 
authors  I don't think that is possible.

But moving PDO to PECL, I think that will be a bad sign for PHP: A key 
point of PDO is to have a common base that is default available on all 
PHP installations. If you remove PDO, scripts will need a ton of wrapper 
and fail-back code again. Then you won't need PDO in PECL too For me the 
strong point for PDO/PHP is the deploy everywhere system even on 
external servers.

Best regards
Oskar Eisemuth