i'm pretty excited about this direction. we certainly can borrow ideas from the definitions in importexportapi module.
- Several modules (e.g. Views) already need schema reflection, this just centralizes the information. It makes it much easier to create new modules that need reflection. A module that wants to support Views or other similar modules can hang any necessary data off its primary $tables array. In fact, many modules will probably not have to do anything more to support such reflection-modules.
aha, so *this* is how we get Views in core :) actually, drupal core itself uses basic reflection on the users table. see user_fields(). an admin can add columns to the users table and these columns will be loaded and saved into the $user object. this table definition API would help us extend that feature to other objects like $node and $term. Very nice for performance.
- Code size reduction and elimination of duplicate code. My automatically-generated schema for core (with all comments) is 110% the size of database.4.0.mysql, but it obsoletes database.4.1.mysql, database.psql, etc. The same reduction would happen in 5.0's system_install().
- A DBMS driver can use inspection statements (SHOW TABLES, SHOW COLUMNS) to actually validate the database layout against Drupal's internal schema, reporting errors.
- It is a huge step towards enabling partial data migration across Drupal systems (this is a whole other topic).
if possible, please document your thoughts on this topic too. building out this vision will support the need for this table definition API