[development] object.module (was nodify.module idea: 'everything is a node')

fago nuppla at zites.net
Mon Jan 22 22:01:13 UTC 2007

Am Montag, den 22.01.2007, 09:54 +0100 schrieb Bèr Kessels:
> I don't like the idea of storing a 'thing' in one table alone. Its not good 
> for performance and horrible when you want to normalise your data. 

I also don't like the idea of a big object table - I just don't see a
need for this.

I would prefer the pair of type string like node/user/vocabulary/.. with
its ID, unique only for its type. I see three pros for this approach:

* better performance
* easier upgrade from currently existing databases
* easier readable object references as you have the type

> Therefore, I think its a much better idea to go the Active Records route: 
> Define good defaults/standards and provide APIs that can pull information 
> from these standardised tables

standardized tables are one way. Personally I don't like it that much. I
think it would be more visible and flexible, if object type properties
are clearly stated somewhere e.g. by a hook which aggregates object type

I also want to point to this interesting issue related to this

Strategy 3 comes close to the "drupal object" idea. I would go and
create the functions


with appropriate arguments. e.g. drupal_read('node', array('nid' =>

Then we could go and generalize the node API to work with all drupal
objects. But probably it's not necessary or useful to apply the full
node API to every drupal object, e.g. the node access system. So perhaps
it would make sense that the object type declaring module states, which
capabilities the object type has.

This could be done with the above mentioned object type definitions,
which are parsed from the API. So we could create object types with
appropriate capabilities and appropriate resource usage.

Basically this is the idea I have in mind, however this needs to be
elaborated further.


More information about the development mailing list