You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 14, 2024. It is now read-only.
I am running into a scenario where, after Quicksand runs and force deletes the appropriate soft deleted models, my database is left with orphaned related models. Normally, I would utilize the forceDeleted model event and create listener a to deal with this - but that doesn't fire since Quicksand does the deletes via the DB facade. Maybe I'm missing something here, but I don't see a great way of dealing with this issue. While utilizing the onDelete('cascade') method in the DB is an option, in this case the related model is another package and that isn't really plausible/easy.
Would you be open to a PR to address this? I'm thinking of two possible solutions here.
1. Perform Delete via Eloquent instead of DB
My thought here is that this would be a config option, to allow you to have the deletions performed via Eloquent instead of the DB. This way, the forceDeleted model event would fire and could be tied into.
2. Dispatch an Event
Again, this would be a config option. My thought is to allow specification of an Event that would accept an array of IDs. Then you could do whatever you want with those IDs in the event.
Thoughts?
The text was updated successfully, but these errors were encountered:
Hey Craig, thanks for reporting this issue. I see what you mean, and we'd definitely be open to a PR to address this.
I'll have to think about this a bit more, but what immediately comes to mind is that we might be able to check if the key in your deletables config is a model or a table by using something like class_exists. If a class exists it must be a model, if it doesn't it must be a table name (since those are the only 2 options).
Then if the class existed, we could trigger the deletions directly via the model. If it's a table we could continue to use the query builder (DB facade) as we have been. This would remove the need for a specific new config option for choosing eloquent vs the query builder.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am running into a scenario where, after Quicksand runs and force deletes the appropriate soft deleted models, my database is left with orphaned related models. Normally, I would utilize the
forceDeleted
model event and create listener a to deal with this - but that doesn't fire since Quicksand does the deletes via the DB facade. Maybe I'm missing something here, but I don't see a great way of dealing with this issue. While utilizing theonDelete('cascade')
method in the DB is an option, in this case the related model is another package and that isn't really plausible/easy.Would you be open to a PR to address this? I'm thinking of two possible solutions here.
1. Perform Delete via Eloquent instead of DB
My thought here is that this would be a config option, to allow you to have the deletions performed via Eloquent instead of the DB. This way, the
forceDeleted
model event would fire and could be tied into.2. Dispatch an Event
Again, this would be a config option. My thought is to allow specification of an Event that would accept an array of IDs. Then you could do whatever you want with those IDs in the event.
Thoughts?
The text was updated successfully, but these errors were encountered: