Deleting of taxonomy terms doesn't trigger index update

in apachesolr.module, we have a TODO for this (i.e. it's a known issue). Patches welcome.

/**
 * Implementation of hook_taxonomy().
 *
 * Mark nodes as needing re-indexing if a term name changes.
 */
function apachesolr_taxonomy($op, $type, $edit) {
  if ($type == 'term' && ($op == 'update')) {
    db_query("UPDATE {apachesolr_search_node} SET changed = %d WHERE nid IN (SELECT nid FROM {term_node} WHERE tid = %d)", time(), $edit['tid']);
  }
  // TODO: the rest, such as term deletion.
}

Term deletion is not easy due to oldness of taxonomy API. When hook_taxonomy delete is called, term_node table is already empty - we have no way of knowing what nodes had the deleted term assigned.

Only way I can think of right now is a separate callback for taxonomy delete form, taking care of the update BEFORE the deletion happens.

Possibly - though that would miss other programmatic calls.

Alternately, we have to duplicate the whole term node table.

That would be ugly...

So looks like the only way to start tackling this is via watching form submission - sad, but it will get us 90% there I think.

I'm trying to understand something here. After deleting some terms via the Taxonomy Manager module, nodes with that tag were not marked for reindex due to this issue. The result is the deleted term's numeric ID shows up in place of the term name in the Apache solr results (because it can't find the term name for a term tagged to a node, only the TID which is stored in the node).

To clear the numeric, dead-end TIDs from the Apache solr results, I visited the Apache solr index page and submitted to "Index queued content". This works. The question is, why does it work? That option simply calls the apachesolr_batch_index_remaining function, the function which looks at nodes marked for needing re-indexing. But these nodes were never marked for re-indexing. So why does it work? (And would there be any problem in simply calling apachesolr_batch_index_remaining in the apachesolr_taxonomy for case 'delete'?)

Any insights appreciated!

Thanks,
Shiraz

@Shiraz: I tried the same, but couldn't reproduce your behavior. That is, I deleted a term that appeared in 2,800+ nodes, went to admin/settings/apachesolr/index, and I only had "48 nodes to index" (due to other changes). Triggering "Index queued content" only indexed those 48, not my 2,800 changed nodes.

In your case, what is the message on that URL? (e.g. "The search index is generated by running cron. X% of the site content has been sent to the server. There are Y items left to send.")

@pwolanin: If I get this correctly, you're suggesting should do a form_alter on the taxonomy_term_confirm_delete form, adding our own #submit callback when "Delete this term" confirmation is given?

@janusman - that was the suggestion, but I have no idea what the "Taxonomy Manager module" is. Obviously such an approach would fail for such a contrib module.

Uh, yeah... other modules deleting terms would be out of our reach with the form_alter approach.

An alternate option is to still depend on hook_taxonomy($op = "delete"), but query against the Solr index to find what is in the index with the deleted term's tid, and then mark those nodes. Would this work?

Well, not sure - how would you handle e.g. 20k or 100k nodes? An IN() query is likely to fail assuming you can even pull back all the data from Solr.

Though given that we index parent terms, that might be most reliable in terms of finding all the nodes that need to be touched.

The only real alternative I can think of is to make a duplicate {term_node} table which would include copying parts of http://api.drupal.org/api/drupal/modules--taxonomy--taxonomy.module/func...

Closing as this is very outdated and no-one seems to respond or care anymore