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

[fago]

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
definitions.


I also want to point to this interesting issue related to this
discussion:
http://drupal.org/node/79684

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

drupal_create()
drupal_read()
drupal_update()
drupal_delete()

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

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.

regards,
fago