AshArchival and FK relationships deleted record still referencing a foreign key

Ash Forum Ash Questions / Help
, ,
1

Hi everyone,

We are using ash_papertrail and ash_archival and encountered an issue.

When soft deleting records, we run into problems if the deleted record is still referenced in a foreign key (FK) relationship. Normal deletions prevent this issue, but it seems that archival deletes do not follow the same behavior.

Is there a way to check for related records before performing an archival delete to prevent these errors?

2

Deleting with ash archival should not cause things with a foreign key relationship to the deleted record to have an error. Could you describe more about the error you’re seeing or what you’re doing? Have you run mix ash.codegen after adding the extension?

3

Maybe I explained it wrong.

We have a resource Ticket which has a field category (points to Category resource).

For example if we use “Category 1” in “Ticket 1” and later delete “Category 1”, this doesn’t give us an error when deleting, but we actually would like to have an error, since it’s used somewhere else. Since via the archiving mechanism we don’t have foreign key checks from the database, is there any other way to simulate a “foreign key check”?

4

Hm…that’s surprising to me. Can you show me your Postgres schema for the archived table?

5

Hi i have a small repo of our problem with a test.

In the test we create a customer with an address. Then we try to delete the address with give us the an error “would leave records behind”. Which is expected. When we add Ash Archival to the resource, the address will be (soft-)deleted.

branches:
master → resources without ash archival
archival → resources with ash archival

6

Ohhhh wow sorry I completely misunderstood (I look at a lot of issues each day and sometimes don’t wrap my head around them fully) :laughing:

You’re saying that you want the error. If you want the error, you will have to do something custom to power that, like add a before/after action hook to do that verification now that the data layer can’t do it. We can potentially add this as a feature to ash_archival but its not supported automatically at the moment.