Pierre Joye ha scritto: > On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE <samuel.r...@aliceadsl.fr> wrote: >> This is a bit complicated and very different ! Actually, each database >> works as it want and it may be better to use different functions for >> each driver. > > That defeats the whole purpose of PDO. The meaning of each message > will indeed different, but if one needs to call different APIs for > each driver, I doubt anyone will ever use them.
Quoting my chat with Rasmus in Verona earlier this year: "PDO is a database driver abstraction layer, not a database abstraction layer", or something along the lines, but I see your point ;) However, I've been thinking about this a bit more and I think that the different "message" meanings can be summarised like this: * MySQL raises warnings, esp. when not running in strict mode * Oracle uses them as a custom way to deliver messages/data * PostgreSQL being a bit of both worlds: informational + custom By all means, I like the idea of a unified "message" API, but do we really need the syntactic sugar (and development effort)? MySQL and Oracle drivers can already access them with a standard PDO::query() call. Only PgSQL notices require a special treatment because they are currently discarded. I guess this is becoming more philosophical question: is the base PDO class intended to only have common and portable functionalities and leve everything else to the drivers or should it also try and group other similar features to be more consistent even though not likely to be portable? Also I guess that mixing and matching names could be confusing: an experienced Oracle developer using "dbms_output" would hardly imagine that they can be fetched by calling getMessages() just by taking a quick look to the documentation. Same goes for a Postgres developer who can easily understand what pg_last_notice() does and would probably not associate the familiar notice concept with getMessages. Sorry for the long post, it's just my 2 cents. Cheers -- Matteo Beccati -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
