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

[Jeremy Epstein]

On 1/27/07, adrian rossouw <adrian at bryght.com> wrote:
> 1) if we end up nesting with entities (and stuff like indexes, and
> relationships),
>      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
nested arrays.

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.

Cheers,
Jaza.