Oskar Eisemuth wrote:

> 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. :(

That would be a much more practical default than the current setup, but I am
seeing many more 'subtle' problems with problems with things like numbers and
dates, where the 'format' is a function of the type of field selected. It is
amazing how some developers can make things dependent on getting a particular
type of result, but everything fails when the 'same' data is returned from
another driver. I can't provide any specific examples at present as I had to
simply shelf the ports and switch bakc to ADOdb. BUT even in ADOdb I should be
able to run 'interbase' and 'pdo_firebird' and see exactly the same data? In the
absence of any planned PDO wrapper, at least ADOdb's pdo driver should provide a
stable base against which to test things?

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

Until such time as PDO DOES provide a common base then there IS little point in
deploying it? Much the same as at present a number of database drivers have been
pulled from the windows builds of PHP5.3. PDO deployment has the same problem as
any database deployment. If the ISP does not provide support then they are not
available. PHP is just adding to that straight jacket.

( Wes - the problem *I* have with Firebird and PHP is convincing the 10's of
thousands of Firebird users that PHP DOES support Firebird. Many of them see
'Interbase' and think that this is another ploy by 'Borland' to switch them back
to proprietary software :( - if Firebird 'is only used by me' how come it does
consistently well in the sf awards http://sourceforge.net/blog/cca09/winners/ )

--
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//
Firebird - http://www.firebirdsql.org/index.php