Cascade delete for relations

[sseypt]

Hello.

• I have created my request on the Product Board before I submitted this issue
• I have looked at all the other requests on the Product Board before I submitted this issue

I'd like to avoid orphan contens by using a cascade attribute to the relation field type.

Cheers,
Steve

[derrickmehaffy]

In the case of cascade to clarify the users request, in this context he means cascade delete, so if a parent is deleted it will delete all children entries as well.

[Aurelsicoko]

I've just created a new card on our public roadmap, please share your insights even if this feature is pretty easy to understand (https://portal.productboard.com/strapi/c/59-cascade-delete).

[luixal]

Any news on this?

Now that Strapi has removed support for mongodb, supporting pure relational feature should be a priority.

[LuizPelegrini]

Any news on this?

Now that Strapi has removed support for mongodb, supporting pure relational feature should be a priority.

you can check the roadmap here and vote for this feature, which is currently in "Under Consideration" tab

[derrickmehaffy]

While it won't be the default in v4, since we will be creating all of the foreign keys by default for relations there will be a way to modify these foreign keys with a cascade delete option. We will provide more information after the v4 is released and we can test these new features.

[ludi81]

How does the cascade delete work in v4? I found nothing in the documentation.

[lnikell]

@ludi81 no changes there, you have to manually declare cascade logic writing a code in lifecycles.js

[derrickmehaffy]

How does the cascade delete work in v4? I found nothing in the documentation.

In the future you'll be able to tweak the foreign key logic to handle cascade delete at the database layer. It's not supported yet nor documented but it's something we are working on.

[JonasJW]

@derrickmehaffy any updates on this?

@lnikell any tips how to do this in v4? I used to do it with the afterDelete lifecycle in v3, the problem is, in v4, there are no relations populated (before the 1st relation layer was), so I can't delete the entries of these relations.

[derrickmehaffy]

@derrickmehaffy any updates on this?

@lnikell any tips how to do this in v4? I used to do it with the afterDelete lifecycle in v3, the problem is, in v4, there are no relations populated (before the 1st relation layer was), so I can't delete the entries of these relations.

Not at this time, we will need to add some advanced custom support to allow modification of the foreign keys which we don't currently have yet.

I'll reopen the feature request though

[M1CK431]

Same need here, especially since there is no way to filter on components (so forced to switch on a dedicated collection with the drawback of orphan in database while deleting the parent).

Personally, I will not do it at code level because it's a database feature/responsibility.

Despite a proper implementation in strapi could take time, writing a simple documentation to achieve the same effect by modifying the foreign key looks like a good workaround. wdyt @derrickmehaffy ?

EDIT: something like this for example: https://stackoverflow.com/a/14381227

[derrickmehaffy]

Same need here, especially since there is no way to filter on components (so forced to switch on a dedicated collection with the drawback of orphan in database while deleting the parent).

Personally, I will not do it at code level because it's a database feature/responsibility.

Despite a proper implementation in strapi could take time, writing a simple documentation to achieve the same effect by modifying the foreign key looks like a good workaround. wdyt @derrickmehaffy ?

EDIT: something like this for example: https://stackoverflow.com/a/14381227

In the v4 you can filter on components just not dynamic zones

[M1CK431]

Same need here, especially since there is no way to filter on components (so forced to switch on a dedicated collection with the drawback of orphan in database while deleting the parent).
Personally, I will not do it at code level because it's a database feature/responsibility.
Despite a proper implementation in strapi could take time, writing a simple documentation to achieve the same effect by modifying the foreign key looks like a good workaround. wdyt @derrickmehaffy ?
EDIT: something like this for example: https://stackoverflow.com/a/14381227

In the v4 you can filter on components just not dynamic zones

Even using graphql? 🤔
I'm not seeing any filter available in the schema for components...

example:

gql generated schema:

As you can seen there is nothing about my communications component in gql available filters 🤷‍♂️

[M1CK431]

For anyone else trying to achieve that, I finally use a mysql trigger like this:

CREATE DEFINER=`somedatabase`@`%` TRIGGER delete_orphan_contacts_details
BEFORE DELETE 
ON prospects FOR EACH ROW
BEGIN 
	SET @contact_details_ids := (SELECT GROUP_CONCAT(contact_details_id) FROM prospects_contacts_details_links WHERE prospect_id = OLD.id);
	DELETE FROM prospects_contacts_details_links WHERE FIND_IN_SET(contact_details_id, @contact_details_ids);
	DELETE FROM contacts_details WHERE FIND_IN_SET(id, @contact_details_ids);
END

In my case the relationship is "prospect has many contactDetails".

Explanation:

• I use a BEFORE DELETE trigger (vs AFTER DELETE) on my prospect table to avoid any issue caused by the foreign key (with ON DELETE CASCADE) which exist on prospects_contacts_details_links.prospect_id column
• I can't benefit from that foreign key because mysql doesn't execute a DELETE trigger when the deletion come from a ON DELETE CASCADE constraint (thanks mysql... 🙄), that's why I'm forced to mimic it's effect in my trigger
• the first step is to get all contact_details ids for the prospect I'm deleting and to store all of them in a mysql var
• then I mimic the ON DELETE CASCADE of the foreign key using the first DELETE statement
• finally I can "cascade" the prospect deletion on my contacts_details table using the last DELETE statement 🥲

Hope it could help others...

NB: if someone found a better way (at DB level), don't hesitate: tell me! 😜

[derrickmehaffy]

Hey all, we are currently moving many feature requests to our new feedback and feature request website to help clean up the GitHub issues and make it easier for us to review bug reports and fix them.

I have moved this feature to the following URL: https://feedback.strapi.io/feature-requests/p/allow-customization-of-foreign-keys-for-options-like-cascade-delete
If you are interested in this feature please feel free to go there and add more comments and/or upvote it there.

For now I will close this and lock it so that all new information goes into our new feedback website.
Thanks!