Complete

NOTE: Conclusions here are provisional and input from a genuine SQL guru would be greatly appreciated.

SQL multiple table delete

Delete rows in three tables that share a key and satisfy a WHERE condition (in one of the tables). Table T3 will have a single row for each of these keys, as will table T2 for that matter, but table 1 will have multiple entries for each key.

The MySQL docs show up to two tables deleted, using three:

DELETE FROM t1, t2 USING t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;

On the Drupal IRC channel, some very useful PHP info:

Selanit: Is there anyway to identify the calling function of a Drupal theme function?

Heine:

<?php print '<pre>'. check_plain(print_r(debug_back_trace(), TRUE)) .'</pre>';?>

It would be possible to do a performance optimization of table structure by moving (or rather, duplicating) the votingapi-calculated score into the cmt tables.

I will revisit this later.

Current thinking is to secretly store a term ID for every synonym

How do we ensure that a term ID that existed once passes on to whatever term Id supersedes it? That is, taxonomy term 12 on example.com, after a lifetime of dedicated service, has been merged into term 18, so how do make sure existing links to example.com/taxonomy/term/12 get you to example.com/taxonomy/term/18?

URL aliases?

Or an addition to the code in taxonomy.module that catches /term?

We'll deal with this later.

cmt_term_description
vapi_id : corresponds to votingapi content_id
tid : same as in term_data
description : same as in term_data. Don't see a reason to put a key on description

cmt_term_weight
vapi_id : corresponds to votingapi content_id
tid : same as in term_data
weight : same as in term_data

name (inserted into synonym-modeled table cmt_term_name, where votes for names are tracked)
LEFT OUT: vid (for now, cannot vote on what vocabulary a term belongs in)

At the U.S. Social Forum in Atlanta I met a person who really wants CMT. (See, even when I'm not working, I'm working!)

It's nice to meet someone enthusiastic about potential!

His name is Sam Boyer, and he's working on the Drupal site Student Trade Justice Campaign.

He also happens to be a linguistics scholar, so I tried to get all his thoughts on taxonomy.

(Short version: Drupal's taxonomy is good, and quite exhaustive for anything one might want to do.)

The mysql data type text cannot be a full unique index. At best a portion (prefix) of it can be indexed. If made a unique index, two entries which start the same for the length of the prefix but have different endings it will cause an incorrect duplicate key error. Which is inconvenient.

Taxonomy terms attach to nodes, not to revisions. Naturally, you don't want to lose all your tags and categorization when a node is edited, but it's worth noting that adding or deleting terms does not create a new revision, that nodes do not keep a history of terms applied to them.

There are differing opinions, and I'm a little scared to look at the guts again after reading this issue, Revisions and taxonomy don't play well.

I hope this will also be useful to people trying to use votingapi to rate arbitrary content, such as the promised fish.

From votingapi_add_vote (which should not be called directly, but is used by )

One thing which is incorrect in the module's in-code documentation is this:

@param $value_type
* An int representing the value_type shared by the aggregated votes.

Two elements of ontologies are not present in standard Drupal taxonomy.

One is that objects be able to have attributes (including relationships with other objects). Objects are also called instances or individuals and are clearly nodes. Attributes can be satisfied with CCK (and for relationships, nodereference).

The second element an ontology should have multiple classes, also called concepts. This is probably best approximated by multiple vocabularies, or perhaps a single hierarchical vocabulary which allows multiple parents.

An ontology's power