Jump to:
| Project: | Drupal core |
| Version: | 5.x-dev |
| Component: | node system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
I have a module which stores some data associated with node revisions, using the VID in my tables. I store the VID, but not the NID, as many third party modules would. I do this because my things (uploaded files) may be attached to node, revisions, users, whatever, and I don't want to have to build in a column for NID when it would be needed only for the one case when my things are associated with node revisions.
Everything works pretty well, except for node deletion. When my hook_nodeapi is called with $op == 'delete', I want to do something like this:
$result = db_query("SELECT * FROM {upapi_data} ud LEFT JOIN {upapi_file} uf ON ud.fid=uf.fid WHERE (obj_type = '%s' AND obj_id in (SELECT vid FROM {node_revisions} WHERE nid=%d))",
UPAPI_TYPE_NODE_REVISION,
$node->nid);
// Then delete each file returned in $result...As you can see, this code relies on the {node_revisions} table to learn which revisions are instances of a certain node.
This code does not work, because all rows in the node_revisions table have already been deleted, by node_delete().
What I propose is that the order of calls in node_delete is changed. For example, to this, where hooks are invoked before anything is deleted:
if (node_access('delete', $node)) {
// Call the node-specific callback (if any):
node_invoke($node, 'delete');
node_invoke_nodeapi($node, 'delete');
db_query('DELETE FROM {node} WHERE nid = %d', $node->nid);
db_query('DELETE FROM {node_revisions} WHERE nid = %d', $node->nid);
// more code here...Is there any reason not to make such a change (I'll I've done is move the node_invokes before the db_queries)? Another option would be to store the revision VIDs in the $node before doing the deletes, so that hooks may access them.
Thanks for any help.
Comments
#1
see #287063: node_delete "leaks memory" due to deleted nodes cached