[development] Database schema abstraction and *reflection*(was: Referential integrity -- finally?)
jazepstein at gmail.com
Sat Jan 27 08:44:01 UTC 2007
On 1/27/07, adrian rossouw <adrian at bryght.com> wrote:
> 1) if we end up nesting with entities (and stuff like indexes, and
> we will end up with a very deeply nested array which could be very easy
> to mess up.
The importexportapi module has entity definitions for all of Drupal
core, in the form of nested associative arrays (as you would know,
Adrian :P). The majority of the definitions have 0 levels of nesting:
they just rely on field referencing to form relationships. A fair
number of the definitions have 1 level of nesting: for things like
node revisions, taxonomy mappings, user profile fields, etc. I don't
know of any core definitions that have 2 or more levels of nesting
(although I spent a fair amount of time getting the API to support 2+
levels of nesting, using recursion).
The reasons for this are:
- 1-1 relationships can be handled with 0 levels of nesting (just put
all the 1-1 fields together into a single flat entity).
- 1-M relationships can be handled with 0 levels of nesting (have a
field in one entity reference a field in another entity), or with 1
level of nesting (put one entity 1 level deep inside another).
- M-N relationships can be handled with 1 level of nesting (have all
the references 1 level deep inside one of the two entities).
- Only 1-M-M, 1-M-M-M, etc. (or M-N-N, M-N-N-N, etc.) relationships
require 2+ levels of nesting, and these are so common that there are
none of them in Drupal core. :P
So actually, because relational database schemas (including Drupal's)
tend to be - by their very nature - relational rather than
hierarchical, it's very unlikely that we'll end up with very deeply
However, despite having said all that, I do agree with Adrian that
using callback functions for running 'commands' on the data is better
than purely relying on an array structure to work out these commands.
More information about the development