Re: PDO Ground Rules

Dan Scott wrote:

1/ The connection string is provided via a connect form, which supplies the driver, and the database details - in pdo format. Question - can I get the driver name from the pdo object, or do I need to maintain that outside the object so that I can apply driver specific checks? ( Additional getAttribute values with string returns? )

My guess would be PDO::getAttribute(PDO_ATTR_SERVER_INFO) would do the trick, but that's just a guess.

Except PDO_ATTR_SERVER_INFO only returns an integer, the same as the other Attributes. Greater flexibility would be provided if they returned the various information as strings - full version number, connection information, operating mode. Otherwise we need to update the driver for every change in the target server? If there is a change of minor version on the server engine then we should be able to check that. PDO_ATTR_DRIVER (string) would make sense? Keep PDO_ATTR_SERVER_* for the remote end information.

2/ We have 'charset=' as an option in the connection string, which obviously requires database specific values. 'role=' is available in the pdo_firebird driver, and other options will be added. So we can modify connection information, but this can only be managed via the connection string? Also, again, this is not accessible from within the created pdo object and so needs to be maintained externally? (getAttribute again? PDO_ATTR_CHARSET has been mentioned but is not listed in the docs)

PDO_ATTR_CHARSET has not been added to the PDO base yet. It seems like a good candidate, though.

PDO_ATTR_USERNAME would be useful as well. If someone is providing then connection information via a an interface, then it would be useful to be able to access what was provided. The same with PDO_ATTR_DSN through which you can also access the ROLE if needs be.

Don't we need some secondary manual pages to start documenting the driver specific variations? Connection details, where a function is emulated or simply unavailable, what defaults are assumed/set, etc.

We do need those secondary manual pages, primarily for connection details and to describe any driver-specific extensions to the PDO interface. We also need people to step up to the plate to write those driver-specific pages. The easiest way to do this would probably be to add "PDO_* functions" entries into the manual, but that would end up making the functions TOC pretty long. Within the docs team I think we need to have a discussion to figure out whether there's a need & way to have the PDO driver pages appear as subsections of the main PDO interface docs.

Somewhere to start hanging driver specific stuff would be nice. We don't want to loading the core documents with it. Only generically available examples should be documented there.

I'm still not sure about things, but if

PDO isn't a replacement for ADOdb, it's a future replacement for ext/mysql, ext/pgsql, ext/oci8, ext/odbc, etc. etc. etc.

as Wez says, then I'm still not getting the whole picture :(

The easiest way to picture it is as a standard set of methods for accessing data, comparable to the existing ext/mysql, ext/odbc, ext/oci8, except: * base set of methods are *standard*: instead of odbc_fetch_row and mysql_fetch_row meaning two very different things, you have PDOStatement::fetchRow() meaning the same thing. This may be the most important aspect of the effort. * methods are object-oriented (syntax is inverted from the existing native interfaces, if you will, but methods are scoped to the appropriate objects) * you can take advantage of PHP 5.x exception handling

But for PDO to replace an existing driver it needs hooks for things other than just the data connection. We have established (as I understand it) that it will not provide generic facilities such as 'SQL mangling' so that SQL specific to the server engine will be required to access such information as list of tables, schemas, databases, etc., but some generic means of accessing an engines services interface will be necessary before the need to run an existing native driver in parallel with PDO can be removed? Backup/restore, starting/stopping, user management - thing on some engines that are not managed via SQL at all, or require connections to the database to be closed before they can be actioned. THAT is what I am having difficulty 'picturing' in the way that PDO is currently structured. I expect to be able to access the database server without necessarily opening a database. That may be possible by providing simply a driver and server name in the dsn, but in my mind I need something more than get and setAttribute to control things. Once I can see HOW to remove the native driver from my code I will not have a problem, but at present both are required, so the incentive to switch is not so strong. That is what I have been trying to get across rather unsuccessfully. SQL Mangling *IS* another layer, but there are still functions that while they can sometimes be handled via SQL Queries, on the whole they need direct server access. -- Lester Caine ----------------------------- L.S.Caine Electronic Services