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

Moshe Weitzman weitzman at tejasa.com
Fri Jan 26 13:59:11 UTC 2007

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

More information about the development mailing list