On 1/27/07, adrian rossouw <adrian@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.