Re: Re: DB_DataObject and MDB

Hi, Hans,

(eg. imagine an medium size project) 40 tables: 10 columns deleted from various tables over time. 20 columns added to various columns over time, 10 columns renamed in various columns over time. (and some renamed more than once...)

Yup ... completely agree that this is a major issue that solutions like MDB / DB_Schema / Propel have yet to overcome. For Propel, someone has promised to contribute (already-written) code that will do differential updates (map XML diff to SQL DDL), but generally speaking updating the database side of the data model is not an easy task.

From that experience, I would almost never suggest keeping database schema in any place other than in the database... - But I know a few others like to think it is feasible... - so the long term plan is to support this..

Yeah, it'll be a pain. I'm just thinking of how some databases allow you to change more information about a column than other databases. In many cases it may require creating a new column and dropping the existing one or something ... could get ugly.

I am discovering that is exactly what is necessary when changing the schema for a datatype-abstracted system. It seems that to completely abstract column changes over the 6 RDBMS systems for DB_Table, you have to... 1. Create the new column with the new settings (name, size, whatever) 2. Copy the values from the old column to the new 3. Drop any indexes on the old column (MySQL becomes a pain at this point) 4. Create indexes on the new column And in that order, too. If you are modifying the data, you have to figure out manually if it's better to do it on the old data first and then copy, or copy then update (the presence or absence of indexes is what drives the decision). The space issues with this approach can become, shall we say, problematic ... but it does seem to work on everything.

Sure, it's a great starting point. XML also has the advantage of being particularly suited to storing more information than needed -- making it a great way to drive things like forms, etc.

Embedded arrays have the same advantage (c.f. DB_Table class properties, which carry info about form elements).

Does DB_DataObject already support these types?

Yeap pretty comprehensive and well tested Date/time/datetime/mysqltimestamp support. (for native types only!.)

Cool -- dunno why I remembered differently from DB_Table discussion. (I'm sure Paul will remind me.) Heh :)

Heh indeed. :-) At the beginning of the DB_Table proposal, DB_DataObject did not have them, but as the proposal discussion progressed over a few months, DB_DataObject continued to evolve and Alan added those types (and I added notes to the proposal text as he made them available, because I'm a fan of full disclosure :-). -- Paul M. Jones Savant: the simple alternative to Smarty for PHP. http://phpsavant.com/ DB_Table: build RDBMS tables and XHTML forms in one PHP class. http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table Yawiki: your collaborative online documentation system. http://wiki.ciaweb.net/yawiki/index.php?area=Yawiki