Re: Re: DB_DataObject and MDB

Hi Alan, Thanks for the thorough responses! -- some more comments inline ... Alan Knowles wrote:

So, am I correct in understanding that in the current DB_DataObject version there is no "official" way to generate DDL from an INI or XML file?

Nope - From the beginning, the existing database has always been the source generator for the schema. (eg. SQL was designed as a DDL, so I thought why not use it ;)

Yeah, I guess I used the term DDL to mean the more precisely SQL DDL. I agree -- SQL is the way to go. What I was wondering was whether DB_DataObject generated SQL based on the INI files, but I think you answered that ("No").

** little story. The initial design of a project I did, the database was done using gtk_MDB_Designer, and in the early stages, I would just wipe out the database, and rebuild the structure from the XML files. However, as we entered beta testing stage, with live data, and real users. dropping the database every time we made a adjustment to the structure became unfeasible. (as live data was now being used) MDB XML has some features for altering tables, but the more you changed the database, the worse, the schema became.. (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.

The XML schema is however very usefull for dumping schema, and recreating it in other databases...

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.

Bit arithemetic is alot faster than string compares.. - and uses less memory.. - thats the logic behind it..

Sure, if you need to parse at runtime -- and if you don't want people messing w/ or creating INI files. (which it sounds like you don't)

Another, Propel-style, solution to this is to create (generate) db "Mapper" objects which provide a static OO representation of the database. (i.e. with methods like getTables(), getColumns(), getIndexes(), getForeignKeys(), etc.)

The whole 20 classes thing (sorry this is probably an exageration), is something that tends to put me off solutions like propel, if there is no simple API that provides 99% of the requirements in a single class, and anything else is an add on (eg. a seperate package).. then I get the sense that the author is trying to solve too many problems.

20? at least! :) j/k, but there are a few classes that describe the mapping, though (DatabaseMap, TableMap, ColumnMap ... maybe one more I'm forgetting). I'm sure there are performance reasons to use an assoc array or other, but I'm willing to pay a performance price for the elegance of an OO solution. -- & considering the only time you really have to investigate the data structure is for performing INSERT statements, most applications never need to touch these classes. Representing things like referenced columns in foreign-key related tables would get too sloppy using any sort of assoc array solution IMO. From a developer perspective, assoc arrays also have the problem of being easy to mess up -- typo in arr index gets hidden a lot easier than a typo in a method name :) I guess I take the opposite perspective on classes; I want more classes with fewer methods rather than few huge classes. IMO this makes for code that easier to customize, debug, refactor and test. But true, probably performance suffers -- especially when using class-per-file model. In DB_DataObject does each row in the db have to be an instance of a class that extends DB_DataObject?

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 :) I have to say that I hate MySQL's TIMESTAMP; there glad I said that, now I feel better. Thanks again for the clarifications & discussion. Hans