[drupal-devel] clipper and relations

[Eric Orton]

On 08/09/2005, at 12:16 AM, Emiliano wrote:

> On Wednesday 07 September 2005 07:03, Bèr Kessels wrote:
>
>> please have a look at http://drupal.org/node/28480#comment-42850.
>> Its a revised proposal for the relation mapping.
>> I came with this after developing my second relation module.
>
> +1 for Bèr proposal

A generic api for handling relationships is a good thing, this is a  
wheel that is reinvented over and over again within drupal and the  
modules.  The latest proposals ability to map any id to any id is  
good for my module too (user_related_content.module, uid <-> nid)

Providing a good API for this will also mean we have far less SQL  
scattered throughout the code which I always see as a good thing too.

> Since we're discussing the relation mapping fields, I'd like to  
> invite you to
> think of 2 other fields: title and description. Although each node  
> has its
> own title and body, when it comes to relations, each relationship  
> may have a
> new title and new description which can be different from those of  
> the nodes.
>
> Examples:
>
> 1 - If you're making a list of books (like Amazon's listmania).  
> Each book
> (from bookreview module) has its own title and body, but when you  
> create your
> list of favorite books, you can make annotations regarding what's  
> important
> in each book, why you recommend them, etc.
>
> 2 - If you're creating a virtual tour using pictures, although each  
> picture
> has its own title and body, since a picture can take different  
> weights for
> several tours, you can have a different title and description for each
> picture in each relationship. (Bèr, think about it for shazam)
>
> There are many other situations... when you add a buddy you may  
> want to
> describe who he/she is, when you bookmark a node you can write a  
> description,
> etc...

The problem is that there is a huge number of types of data that may  
make sense to store with different relationships.  I think we should  
actually take the description (in the current proposal) of what the  
type of relationship is out of the relationship table and put it into  
a relationship_type table.  i also think most of the 'extra'  
information modules may want to associate with a module should be  
maintained in a separate table (much like we 'extend' nodes  
currently, let's leave the base relationship as a simple common base).

Of course, I'm biased as this is the approach I took in  
user_relationship_module (the api in there is generic to store and  
retreive many 'different kinds' of relationships, and apart from the  
explicit naming of uid and nid is close to being very generic).

Cheers,
Eric