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