Re: [PDO] Mapping data type/size

On 29.10.2009, at 08:48, Lester Caine wrote:

> Lukas
>
> I think this is the key point I was asking about ...
>
>>> The bottom line is that we have to know the structure of the table  
>>> before we can use it? We can't simply ask for those details from  
>>> the database and adjust things accordingly?
>
> ADOdb returns the metadata for a table or query, and then the  
> drivers can modify operation to provide a compatible result across  
> all sources. This is the area that PDO does not currently support -  
> if I'm reading the information correctly? There is an experimental  
> meta data call on the result, but not for the prepared query or for  
> tables in the database?
>
> It also looks like the reason that the PDO driver 'in' ADOdb is  
> unable to actually do some of the automatic data matching magic :(

yes, this functionality is definitely missing. I remember that someone  
was looking at this a while back already. Ah there is experimental  
support available it seems:
http://ch.php.net/manual/en/pdostatement.getcolumnmeta.php

> In theory I should just be able to switch between Firebird and  
> PDO:Firebird in ADOdb and compare results, but at present much of  
> the information needed is not available from PDO. One has to  
> manually feed in the fact that a field is a character string rather  
> than a blob, but even that can't actually be handled in PDO currently?

see if the above is implemented in the current firebird driver.

> I'm not trying to be difficult, but I can't currently see how to  
> make PDO work for me with Firebird which is why I can't even get to  
> the debugging stage. Until I can get it to transparently handle the  
> data problems I can't even start looking at other aspects. And it's  
> not just Firebird, Oracle has the same problem with CLOB ...

the good thing is that we are now looking at what is missing in pdo.  
reading metadata from results needs to be supported as good as  
possible, because that is something that you cannot even do from  
userland.

the next topic that was also frequently raised is reading the  
information schema. its tricky as stuff like this changes over the  
course of different versions of each rdbms, but its doable. i think  
adodb has partial support for this as well .. mdb2 and doctrine are  
fairly complete across their respective drivers. so we can use those  
for inspiration .. not sure if any rdbms lib supports a C api for this.

> The real question here is WHAT is the base that PDO is working on  
> currently? Having been through the steps of hand converting a MySQL  
> database schema into one that will work with Firebird in order to  
> test PDO - ignoring the SQL problems - one finds that the 'normal'  
> mappings that I've been using ( and describing in conference papers  
> over the last 5 years ) simply do not work with PDO. Yes I can  
> ignore BLOB fields and map to something that works, but in CMS  
> systems, that considerably restricts the size of the content. So do  
> I need to restructure the pdo_firebird driver so that it does not  
> use streams by default just to get to a state where things can move  
> forward?


well lets say .. pdo was created with oracle in mind mostly. however  
all feature requests there on out where quite focused on mysql.  
anyways, i think the above link basically means we just need to move  
this function out of experimental stage and make sure its available in  
all drivers.

regards,
Lukas Kahwe Smith
[email protected]