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

[Peter Wolanin]

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 at jaspan.org>
To: development at 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):