I have a term reference field called 'field_product_discount_bonus' referencing terms from the vocabulary 'discount_bonus' which is referenced by entity 'commerce_product'.

If I delete a term from that vocabulary, the database table 'field_data_field_product_discount_bonus' still holds records for the deleted term tid in 'field_product_discount_bonus_tid' and this is reflected if I use the following code to find a deleted term id:

<?php
  $query
= new EntityFieldQuery;
 
$query
   
->entityCondition('entity_type', 'commerce_product')
    ->
fieldCondition('field_product_discount_bonus','tid',62,'=');
 
$result = $query->execute();
?>

Surely such database records should be deleted from the system? Is there a reason to keep these records around for historical reasons, otherwise it's just taking up space.

Comments

Status:Active» Closed (duplicate)

Status:Closed (duplicate)» Active

Sorry to re-open, just making sure as I can't see any mention of this issue from that which you marked as dupe of.

Issue #1065814: Vocabulary terms remain after removing field from content type is about removing a taxonomy field, whilst this issue is simply above deleting a single taxonomy term.

Please feel free to mark as dupe again, but I just wanted to make that distinction as the duplication is not so clear to me :) Thanks!

I ran into the same problem. Deleting terms with taxonomy_term_delete() or field ui does not remove term references to the deleted terms from fields of type taxonomy_term_reference.

I was wondering why this thread is so empty. I feel like this is a major issue.

Component:entity system» taxonomy.module

I would say this issue is rather related to the taxonomy module. Maybe the taxonomy module's own implementation of hook_taxonomy_term_delete() should take care of deleting depreciated term references.

I agree that this is a major issue.

@Jve: I don't see this issue as relating to the issues you linked. The problem needs to be solved by whatever module provides the field (probably by implementing hook_entity_delete). In this case the module providing the field is the core taxonomy module and it should take care of all relevant cleanup in its taxonomy_taxonomy_term_delete function (or taxonomy_entity_delete).

Priority:Normal» Major

I'm going to bump up priority to see if it can get a little more attention. This has been crippling almost all the D7 sites I've been rolling out lately.

I looked into this a bit more. I suppose the trouble is that the right way to do this is to actually re-save all affected entities using something like field_attach_update so that other modules have a chance to act on the change. The potentially large # of entities that need acting upon dictates a queue or batch-based approach.

#89181: Use queue API for node and comment, user, node multiple deletes is not an identical issue but I think any proper solution for this issue will require waiting on that one.

That said, would it be worth entertaining other, short-term options? The current state of affairs means that you really can't delete a taxonomy term without fear of breaking entities that relate to that term. Perhaps I'll write a contrib module that does the deletion directly in the DB rather than doing it via the proper "update all the entities" approach. It's not optimal, but it's almost certainly better than totally broken entities.

@azinck: this issue is exactly the same as those other issues. Namely that references to "things" are not cleaned up when those "things" are deleted.

I'm not saying this issue is a duplicate of those others. This one refers to the problem with taxonomy. The others are for nodes, users, cck fields and entities.

What I'm trying to do is to make people aware of the fact that the same issue ("referential integrity") has been around in several Drupal modules for many years and that there are a few people discussing different approaches to solve it in different issue queues.
So please check on those other issues to see what is involved and what pitfalls there may be.
Like "When a term reference field is marked as required and one or more nodes have that field referencing termA, should the user be asked for confirmation when trying to delete termA?"

If you take care with your EFQs and Views it is possible to work around most of the problems caused by these invalid references. Which may be a better short-term option than direct DB deletion, which can cause problems with caching amongst other things.

When I get some time I'm going to do some benchmarking with cleaning up entity references on large entity counts for #1368386: Delete references to deleted entities.

Version:7.x-dev» 8.x-dev
Status:Active» Postponed

This isn't a major bug, it's been 'by design' in CCK for years, and the same was transferred to core when Field API landed.

Having said that, once #89181: Use queue API for node and comment, user, node multiple deletes it would be possible to batch this clean-up, so let's mark it postponed on that issue.

Priority:Major» Normal
Status:Postponed» Active

I suppose the trouble is that the right way to do this is to actually re-save all affected entities using something like field_attach_update so that other modules have a chance to act on the change.

It's actually not totally clear that's the right way to do it. Saving a bunch of entities that didn't actually change (but that just had some stale references cleaned up) could actually lead to unwanted side effects. See @sun's point #1 at #556022-68: When a text format is deleted, some modules (like text.module) don't update their data, even though we say they do for discussion of a similar problem.

Given that, I think we should tentatively un-postpone this issue.

Perhaps I'll write a contrib module that does the deletion directly in the DB rather than doing it via the proper "update all the entities" approach. It's not optimal, but it's almost certainly better than totally broken entities.

I actually just posted such a module (as a sandbox project for now): Field reference delete

Thanks for that, David. After reading through the text format issue you linked to I understand the nature of the problem much better.

I like your solution and I think it's probably the "right" one for SQL databases at least, but based on the dialog on the text format issue I suspect you have a long row to hoe with respect to getting it into core.

Taxonomy Orphanage also helps resolve this issue, but of course this should be fixed in core.

Yes I vote that this should be addressed in core. I spent hours of my life today before finding a post for taxonomy_orphanage

Please fix !!

This really should be major - I think it's a pretty significant oversight for a commonly occurring workflow which used to work without issue in D6 but now causes a fatal error. Don't know how that could possibly not be considered major. ;-)

I tried Taxonomy Orphanage, but it doesn't work (AJAX error when running the round up batch job). We're forced to just do a SQL query and then tell the client they can't delete terms for now.

Note that Drupal core does not have fatal errors due to this situation (at least not to my knowledge), but some contrib modules do (and I have therefore seen fatal errors on particular sites as a result of this).

Field Reference Delete (which I already mentioned above) should work fine for allowing people to delete terms going forward. I really ought to promote that from a sandbox at some point...

For cleaning up broken references that already exist though, yeah, if Taxonomy Orphanage isn't working for that then a direct SQL query may be the only option.

i have this issue every time i run cron. my question is, how can i find the malformed entities? taxonomy orphanage didnt help a bit.

@liza:
Try also Field reference delete module: http://drupal.org/sandbox/drothstein/1775816
If this doesn't help, see the example sql query here (at the bottom): http://drupal.org/node/1778572#comment-7256200