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

I think I can get away with keeping the DSN connection string, and then allowing for an additional, optional config param to indicate a non-PDO DB adapter to use after I've added the ability to do so. thanks for the good feedback! -L On 9/17/07, Travis Swicegood <development@domain51.com> wrote: > > I wouldn't consider it a show stopper - more of a would definitely be > nice feature. That said, this would be the time to make that sort of > a change, otherwise you'll have BC considerations to make when adding > in the new way of passing in a database. Granted, it might always be > nice to allow a DSN and utilize whatever database object is available. > > In the end, it's more a matter of what you're comfortable with, > however, not what I think :-) > -T > > > On Sep 17, 2007, at 1:45 PM, Luke Crouch wrote: > > > 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 > >> > >