Re: Re: [PEPr] Comment on Tools and Utilities::DbDeploy
| From: | Travis Swicegood | Date: | Mon, 17 Sep 2007 19:59:17 +0000 |
| Subject: | Re: Re: [PEPr] Comment on Tools and Utilities::DbDeploy | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-48035@lists.php.net to get a copy of this message | ||
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