[development] relationships API vs i18n

[Jeff Eaton]

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.

--Jeff