Nodereference filtering: invalid reference should be same as no reference

This is probably because the node reference module does not touch a reference field when the referred node is deleted.

I would suggest trying http://drupal.org/project/cck_referential_integrity

As a feature request, I'm afraid it won't happen. That's why I wrote that module.

For the record:

- #83929: referential integrity
- #362649: Inconsistent site left after deleting a parent referenced in a nodereference field

So the other issue was first. This one is a dup of #362649: Inconsistent site left after deleting a parent referenced in a nodereference field. Note that yched said "won't fix". And I'm afraid this won't happen in CCK for D6. You may try to see how this is being addressed in Fields in D7.

Have you tried adding a relationship for the corresponding nodereference field and setting this relationship to required?

Well, if you need to check if the nid on a nodereference field points to an existing node or not, you need the relationship, no?

AFAICT, the empty filter just works. I think you really mean CCK needs a valid reference filter, and this is something that can only be done with a join, which is what the relationship provides.

However, the correct way to deal with this is that something would have to ensure deleted nodes are dereferenced, but it was said "won't fix", and that's why I implemented CCK I.R. module.

Please note I'm almost alone dealing with CCK issues, and I'm just trying to help you address a problem. CCK for D6 is basically feature frozen because no one is working on it. CCK developers are busy with Fields in D7, and any relative complex change here will probably be discarded. If I was under your skin, I would try to look at how things are being done with Fields in D7, and try to help there. Anything we do here may lead to nowhere if that's not implemented for Fields in D7.

Move to new References module.

Categorizing.

I just tested the mechanism described by markus_petrux at #6 on the current reference 7.2 and views 7.3 version and it works well.

Since References is essentially a port of nodereference/userreference instead of a new complete solution, and that workaround works well, I'm inclined to won't fix.

Typo: #8, as you probably guessed.

This really is a feature request, since the behaviour is identical to CCK D6. Accordingly postponing since we only do bug fixes until we have a stable release, at which point features will be reactivated.

This certainly seems achievable without a lot of effort.

1. Delete node X.
2. Use Field CRUD API to discover all fields of type 'node_reference'.
3. Use EntityFieldQuery to find all nodes referring to node X.
4. (a) Load these nodes and resave without deleted node. (Do we create a new revision with a note? Maybe that's an option.)
5. (b) Delete this reference for all revisions of referring nodes.

I'd be glad to take a crack at solving this problem in anticipation of a stable release (2.0-beta3 seems pretty stable to me). Does this approach sound like the correct method? If so, I'll see what I can figure out.

If we could assume field data is only in SQL, this could be done much easier with a single DELETE query for each node reference field. Since we have to support other storage backends, this won't scale for a large site with many nodes. Batch API is the next step. Should it be taken down even further to be usable only via cron?

Also, do we delete any existence of that nid in past revisions as well? If we only change the current revision, that may or may not be the published revision (@see Workbench).

Subscribe. This would be great to have working. It's not causing any problems on my site, per-se, but it's annoying that the extraneous data is present until someone goes in and re-saves a node with a now-nonexistent reference.

P.S. The title seems very vague to me, but I didn't read through this issue in detail. I vote for something more like "References not deleted when referenced entity is removed."

The problem is performance : find the nodes that reference the field that is being deleted is one query per noderef field existing on the site. Then we get an arbitrary number of nodes. We need to update field values for all those nodes. This can make the execution time for a node_delete() explode arbitrarily.

Keeping references to deleted entities is also what the core taxo / file / image fields do, for that matter. Invalid references are wiped out on display. But yeah, those can fool views.

A possible approach :
1. store nids of deleted nodes and perform the cleanup on cron
2. unfool views by forcing handlers for noderef fields to join back to the node table. This only needs to affect the argument and filter handlers : there are no sort handlers for noderef (eek, actually there is - there shouldn't be, we removed them in CCK D6, sorting on nid makes no sense), and fields do not take part in the query.

Side note :
1. basically means porting and integrating http://drupal.org/project/cck_referential_integrity, and hooking it on cron. Won't happen overnight, if ever
2. is possibly quite straightforward, I'll look into this.

"forcing the argument and filter handlers for noderef fields to join back to the node table" :

I started that, it works, but the trouble is that when the view additionally has a relationship on the noderef field (with option "require this relationship") , then we get two INNER JOINs on the node table that are not de-duplicated, because the add_relationship() method does not use ensure_table() but directly adds the table.

So, since that the current noderef arg and filter could completely be reproduced with the noderef relationship (relationship + filter/arg on node:nid through the relationship), I'm not sure keeping them makes any sense if they either :
- can be fooled by deleted nodes
- or are made more bullet-proof at the cost of a JOIN will be duplicate if the view uses an actual relationship.

I'll try to ping merlinofchaos and dereine to get their thoughts on this, since this pattern also involves Views' own arg and filters for taxo / file / image fields.

First, I have very little idea what this thread is about so this might not be the correct place to put my comment.

My situation is that I have a product listing that users can attach reviews to. The reviews might be comments but they are not. There are also other node references attached to each product like a photo and administration notes. I'm not sure why I didn't use comments because they are fieldable perhaps I just didn't like the interface. However, when I delete a product there is no reason to have reviews that reference that product and they should be deleted too. I found the solution in comment.module which looks up all the cids of comments attached to a node that is being deleted and then deletes all of them.

Here is my solution:

/**
 * Implements hook_node_delete().
 */
function helper_node_delete($node) {
  if ($node->type == 'product'){
    $nids = db_query('SELECT entity_id FROM {field_data_field_review_reference} WHERE field_review_reference_nid = :nid', array(':nid' => $node->nid))->fetchCol();
    node_delete_multiple($nids);
  }
}

There are a few things that References can work with here. First, it can use the hook_entity_delete() function to look up all fieldable entities that have a reference field attached to it. Second, all the information about the references are contained in the field_config and field_config_instance tables of the database. This can be queried instead of the hard coded example I have to determine if a node or entity has another node or entity with a reference to it. User options to manage orphaned references can be set with the hook_field_widget_settings_form() function. Last like the comment_delete_multiple() function in comment.module which has to also delete each comment's replies a custom function can be recursive to see if the deleted nodes that reference a node being deleted also have other entities that reference it.

@Adam S : yes, but see my considerations on performance in #22.

subscribing

Here's a port of http://drupal.org/project/cck_referential_integrity to Drupal 7

http://drupal.org/sandbox/claudiucristea/1263038

The main change from the D6 version is that all updates on entities are queued, using Queue API, and then processed at cron.

Fell free to test the module and use the issue queue here http://drupal.org/project/issues/1263038 to send your feedback as bug reports or feature requests. After some testing and input from the community I will promote the project as permanent project.

#1346696: On deletion of node/user, references to it are not removed is an post specific to that the records aren't being cleared. Not sure which is duplicate.

(A table should be clearing out data about nodes/user on deletion -- that is a bug. Having a contrib module solve a bug with another seems a bit overdone).