[development] relationships API vs i18n
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