Corresponding node reference not updated when unchecking node reference

I confirm this bug.
Fix is to clear cache when the away node changes. Will be implemented in 6.4.2

I'm not sure this is the solution. I found this same issue and believe I found the problem. The logic for determining what relationships are new, old, added and removed involves loading the old node from the database. I believe the problem is that the operations are being called on $op = 'update' not in corresponding_node_references_nodeapi. This function is called AFTER the database has been updated. So, the nodes being compared are the same.

The current code is:

function corresponding_node_references_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {

  switch ($op) {
    case 'insert':
    case 'update':
    case 'delete':
      corresponding_node_references_process_node($op, $node);
      break;
  }
}

The solution that worked for me is (keeping $op = 'update' to keep the change in one place. I would change the function name to corresponding_node_references_update() in the crud file for an actual fix.):

function corresponding_node_references_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {

  switch ($op) {
    case 'presave':
    	corresponding_node_references_process_node('update', $node);
	break;
    case 'insert':
    case 'delete':
      corresponding_node_references_process_node($op, $node);
      break;
  }
}

I believe I have a similar issue, but if different, I can start new thread. When node A is updated because node B's node reference to A's node type is changed, the code updates the database correctly via content_update(). However, I noticed the data isn't immediately apparent because node A's record in cache_node still exists (and hasn't been updated since B was edited).

To fix it, I added the following after content_update() is called from _corresponding_node_references_update():

  if ($exists = db_result(db_query("SELECT cid FROM {cache_node} WHERE cid = '%s'", 'node/'. $node->nid))) {
    db_query("DELETE FROM {cache_node} WHERE cid = '%s'", $exists);
  }

Is this a valid bug, or should I pursue this another way?
Thanks for any input.

The approach in #3 solves the problem but only in case of viewing the node directly. I wonder if one can do anything in an effective way for other appearences of the node (e.g. frontpage, views...). Any idea on this would be appreciated!

If not using cache_node, Drupal finds the node's content/fields via database tables, right? How are frontpage and views grabbing node content/fields then? How should we modify our method?

I do not have a cache_node table but a cache_page. But I assume we are talking about the same thing.

In the case of the front page the page is cached in the cache_page table under the cid http://example.com. I don't know if there is an efficient way to extract information if the changed node appears on the front page or not (and therefore it is necessary to clear this line in the table).

With views I suppose the cache tables are cache_views and cache_views_data. I don't know anything about these.

Sub

This patch solves the serious issue of this module not maintaining relationships properly with the approach in comment #2.

I think caching issues should move to another thread - they are not as critical.
Bumping priority and version.

Aaron's patch from #8 re-rolled to apply a little more cleanly against 6.x-4.x-dev.