[development] relationships API vs i18n

Jeff Eaton jeff at viapositiva.net
Fri Nov 10 15:46:45 UTC 2006

Robert Douglass wrote:
> The last few posts to this thread assume that we need to generalize the 
> API *and* generalize the storage table. A lightweight triples API could 
> take a table name as a starting parameter (with a sensible default, of 
> course), and then modules like the buddylist could add their own triple 
> table but still use the API.
> So before we start pouring cement around our database foundation, lets 
> try to identify the types of functions we want in the API. Aside from 
> putting triples into the database and getting them out again, what 
> would, say i18n need?

Here are a couple of the priorities I came up with when I made my attempt:

1) Must be able to capture different relationship types. (Standard 
taxonomy terms used the 'describes' relationship type. Book pages used 
the 'child_of' relationship type.

2) Use an actual ID for each relationship. Currently, node/taxonomy 
intersections have no id, so it's impossible to hang other meta-data 
tables off of them.

3) Capture optional weight, so relationships can be ranked.

4) Capture an optional uid, so that relationships can be user-specific.

If we add to that the ability to break things out into custom tables for 
optimization purposes, the way cache tables work in 5.0, I think we have 
a real winner. My schema worked out to something like this:

rid int(10) NOT NULL auto_increment,
source_id int(10) NOT NULL default 0,
relationship_type text NOT NULL,
target_id int(10) NOT NULL default 0,
uid int(10) default NULL,
weight tinyint(3) NOT NULL default 0,

I also had a small .inc with helper functions in my sandbox. The real 
problem isn't, IMO, writing this kind of glue. It's converting the 
monsters like taxonomy over to the new schema.


More information about the development mailing list