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

marcingy’s picture

Status:Active» Closed (duplicate)
carn1x’s picture

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!

davidn’s picture

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.

davidn’s picture

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.

JvE’s picture

azinck’s picture

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).

azinck’s picture

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.

azinck’s picture

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.

JvE’s picture

@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.

catch’s picture

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.

David_Rothstein’s picture

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

azinck’s picture

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.

LoMo’s picture

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

kclarkson’s picture

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 !!

seanr’s picture

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.

David_Rothstein’s picture

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.

kenorb’s picture

kenorb’s picture

liza’s picture

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.

kenorb’s picture

@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

jibran’s picture

Component:taxonomy.module» entity_reference.module
Issue summary:View changes

Term Reference Fields field has been removed from D8 in #1847596: Remove Taxonomy term reference field in favor of Entity reference. If this is still an issue then it is generic to ER so moving it to ER queue if not then we can move it to D7.

Berdir’s picture

Yes, it is a generic problem. user.roles has a custom solution for this using UserStorage::deleteRoleReferences(), I've wanted to open an issue for a while to implement that in a more generic way. But it's not that easy to make a performant solution.

amateescu’s picture

It's not only a performance problem, we also need to allow site builders to opt-in (or out) for this behavior :)

jibran’s picture

Title:Database records not deleted for Term Reference Fields after Term is Deleted» Database records not deleted for Reference Fields after Reference is Deleted

More generic title.

JvE’s picture

Title:Database records not deleted for Reference Fields after Reference is Deleted» Database records not deleted for Term Reference Fields after Term is Deleted
Version:8.0.x-dev» 7.x-dev
Component:entity_reference.module» taxonomy.module

@jibran: ER already has a ticket for this issue: #1368386: Delete references to deleted entities
This ticket was specifically for Taxonomy. Since taxonomy no longer deals with references in D8, this ticket can be moved to D7.

Alternatively it can be closed as [works as designed] because it looks like the Drupal stance is to address this in contrib with Field reference delete.

jibran’s picture

Now we don't have any issue against D8.

David_Rothstein’s picture

There definitely should be an issue filed about this for Drupal 8 somewhere. Whether it should be this one or a new issue, I'm not sure...

JvE’s picture

Well, people have been trying to get this fixed in core and contrib for 4 years, but none of the core or contrib maintainers have been willing to address this issue.
I guess we'll just have to accept this as another drupalism to be handled in contrib.

On a side note: Am I to understand that Entity reference was moved into D8 core but the issues filed against it were not?