Re: PDO Ground Rules

On Mon, 14 Feb 2005 06:13:42 +0000, Lester Caine <lester@lsces.co.uk> wrote: > OK - Until Ard bring pdo_firebird in line with the current pdo code, I > am a little stuck. I've spent more time going back over what I CAN test, > and have produced a 'fault report' for Ard, but a few more questions pop > up. DON'T chew my head off, because it may simply be that I can't yet > test something. > > 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. > 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. > 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. > 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