Re: [PEPr] Comment on Database::DB_Table

On Mar 23, 2004, at 7:37 PM, Alan Knowles wrote:

SQL is probably the best method for changing structure after a project starts. (although not very portable)

You got it. ;-)

At present in DB_DataObjects, I very frequently modify table after project starts. (even on live servers) - clients have a horible habit of changing their minds.. :) Process: - using mysql command line to run ALTER TABLE command. (store this in some text file somewhere) - run createTables, to update the code to match the database table. If I need replicate the change to another server - the process is just to run the sql commands. In DB_Table logic. Process: - modify PHP code manually - modify sql manually to match.. (or just drop and let the class automatically recreate the database) there is a slight risk that this approach introduces bugs

This is a fair and accurate assessment of DB_Table; for myself, most of the changes happen as I am creating and testing the tables and classes, and I just drop the affected table as I go. In practice, I've not had to modify a production table, but YMMV. I think I mentioned earlier, though, that I am working on a "discover" or "setupFromDB" method to look at the table and get the columns and indexes from it directly. (It's on my mental to-do list; I suppose I should put it on the wiki, too.) This may obviate much of the form-building power of DB_Table, but for getting or converting existing tables it will be useful.

I would generally say the trade off on DB_Table is future flexibility against installation ease and database portibility.

In general I must agree with you: DB_Table does require a level of stability in the tables themselves that some developers may not be able to meet. In practice, this has not been a significant issue for me, but again YMMV. Having said that, DB_Table is targeted (among others) at developers who wish to distribute their solutions to a wide range of end-users. For these developers, the table setup must by definition be stable *before* distributing their code, and any changes to the tables in the distribution will require a migration instruction set regardless of what database tool is used. -- Paul M. Jones pmjones@ciaweb.net Savant: the simple alternative to Smarty. http://phpsavant.com/