Re: Re: [PEPr] Comment on Tools and Utilities::DbDeploy

hmm ... yeah, that's a very good point. do you think that is a show-stopper? i.e., should shoot down the proposal for that? or think I can just add it as a feature request on the project tracker and implement it ASAP? -L On 9/17/07, Travis Swicegood <development@domain51.com> wrote: > > On Sep 17, 2007, at 1:24 PM, Luke Crouch wrote: > > > it utilizes the new PDO extension and those drivers for db > > connection abstraction, so you can connect to any db platform via a > > connection DSN in the config file. > > > > but it doesn't use MDB or any other fuller db abstraction for the > > data-types. I wrote the syntax objects into it merely because I > > think it only deals with 1 data type abstraction - DbDeploy doesn't > > actually perform the schema changes. the only time it connects to > > the database is to check the schema's version via the changelog > > table. so really, DbDeploy only ever operates on that single table, > > and that table has only 1 column of an "odd" data type (timestamp > > field). so I thought adding on full-out db abstraction for that 1 > > field might be overkill and give it a frivolous dependency. > > > > so it uses PDO & PDO drivers installed into PHP 5+, but does not > > use the other PEAR DB packages. > > > That does make sense, but what about wrapping PDO in a > DbDriver_Database_Pdo object that implements a DbDriver_Database > interface? It does add a little overhead, but it also provides a > flex point for people to implement a driver that utilizes their own > database API where appropriate. The case that's coming into my mind > right now is the developer who has a box without PDO enabled. > > -T >