[development] Database schema abstraction and *reflection* (was: Referential integrity -- finally?)

[Moshe Weitzman]

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