Re: [development] Database schema abstraction and *reflection*(was: Referential integrity -- finally?)
I was wondering if the model code for the new forms API might be a good place to start for syntax. Wouldn't it be cool if the way we talked about data for the model portion of a form would be the same as the way we talked about data in the schema? Or does that seem silly? Anyway I love this idea, as it opens the door for much more postgres or other db support. The lowest common demoninator for DML is much easier to achieve than in the DDL in my experience. Dave
On 27 Jan 2007, at 12:17 AM, Metzler, David wrote:
I was wondering if the model code for the new forms API might be a good place to start for syntax. Wouldn't it be cool if the way we talked about data for the model portion of a form would be the same as the way we talked about data in the schema? Or does that seem silly?
Might be useful, but the model portion is required for normal operation. I don't know that we want to move the data structure to generate tables moved into the module files at this point. It is definitely an idea for the future though, although the primary use of this would probably be for a query builder, and I just don't see Drupal 6 including a query builder. There's a couple of major reasons that I still think functions are better than a single data structure however. 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. 2) individual commands (ie: create table, create index), allow us to use the same code for the updates too. if the schema is documented in a big array, we will be in a situation where we have to maintain the commands as well for use in updates. Or we try to analyze changes in the array structure to generate the commands automatically. This is a direction I don't think we should move towards, as there be dragons there. 3) easier to debug. nuff said. -- Adrian
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.
I like Barry's idea as a whole, but when I saw several levels of brackets nested, I was a bit taken aback. Not only easy to mess up, but hard to read, understand and maintain. So I agree with Adrian on this. Which leads to what Adrain said: 3) easier to debug. nuff said.
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.
participants (4)
-
adrian rossouw -
Jeremy Epstein -
Khalid B -
Metzler, David