Description: ------------ As you know each field in a DataObject has a comment after it containing the field type, length and associated flags: I.E. public $user; // int(10) not_null primary_key unsigned auto_increment public $tag; // string(255) not_null public $url; // string(200) not_null multiple_key public $description; // blob(65535) not_null blob I would find it really helpful if this information was contained in an associative array within the generated class. I.E. $__fieldDetails['user']['type'] would equal 'int' $__fieldDetails['tag']['length'] would equal 255 This could help in a number of ways, however the main reason I currently want this feature is for strings so I can see the length at which a string would have been truncated. Say for instance I I have a value external to the database and I want to compare to a value that I have pulled from the database. If the database value had been truncated due to the field length, then in order to see if the two values match, I need to know field length so that I can truncate the external value by the same amount before the comparison. Being able to access this data, would also help with setting up a simple form of automated validation based on the field length and type. Sending a message to the user if they enter a value outside of these bounds. ----------- Side note: Cheers for your work on DB_DataObject, it allows me to work so much faster and bug free.

this is really available directly from the DB package, something like $db = $dbo->getDatabaseConnection(); $array = $db->tableInfo($db->tableName());

Firstly, thanks for the response Alan. Yes this is already available inside of the DB package, but really so is everything else that DB_DataObject does. Here are my reasons for wishing it to be in DB_DataObject: 1. The code (currently used to add the comments) is already there for easily adding the additional information? 2. It would save people the hassle of using two interfaces for each table, just so they can get some simple details about the fields of that table. 3. Just like the fields of the table (which are prebuilt into the table classes), the format of those fields will also remain static; so having them prebuilt into the class makes just as much sense for both efficiency and ease of use. 4. I'll be your bestest friend. 5. Lastly, if all these things aren't convincing enough, I'll add that it of course it wouldn't need to be built in by default, it could just be an option in dbConfig.ini for those who would find it useful.

Hmmm... after thinking about it some more, your probably right. Perhaps that way is the best. After rethinking, I'm not sure precoding it would achieve any noticeable efficiency gains. Thanks for setting me straight.