Yes, I'm really behind this idea- I just didn't know what it was called before! This seems top be a requirement for being able to write generic drupal_load(), drupal_save(), etc. functions to reduce the total codebase and handle almost any type of object in drupal. http://drupal.org/node/79684#comment-184791 -Peter --- From: Barry Jaspan <barry@jaspan.org> To: development@drupal.org Date: Thu, 25 Jan 2007 19:03:12 -0500 Subject: [development] Database schema abstraction and *reflection* (was: Referential integrity -- finally?) I raised the issue of database schema abstraction last summer, and I know that other people raised it before me. The arguments this time seem to be the same as the used to be (though apparently Dries is closer to being persuaded :-). I would like to elaborate on my primary reason for supporting a database schema abstraction layer (not for data manipulation (SELECT, etc.), just for CREATE TABLE, ALTER, etc): database schema reflection. Schema reflection will provide Drupal the ability to understand and manipulate its own data schema (in the flavor of the Forms API). Every table's structure will be defined in a data structure (just like a form), indicating its columns and data types, keys, etc. I envision something like this (I wrote a perl script to automatically generate this structure by parsing 4.7's database.4.0.mysql. Other methods are possible, but it only has to be done once):