Change remote FK on ACS model to on_delete=CASCADE#7748
Conversation
ACS objects shouldn't prevent Remotes from being deleted. This was primarily an issue with replication, where creation and deletion of remotes is mostly hands-off. Why CASCADE instead of SET_NULL? the serializer requires one on deletion, and deleting the remote would orphan it (leaving it nonfunctional) anyway, so it seems like the best option?
|
All I can say is we were told that replicated systems were supposed to be completely hands off. Just to get the full picture: We try to delete the remote, because we presumably created it while replicating it a prior run. So we assume it is "owned by replication". Now a user thought: "Oh nice remote you have there. Let me use that." What if we just didn't remove it then (PROTECT but failsafe), unless we can protect everybody from doing such a thing? |
|
Yeah I do think this is a bit of scope creep, but perhaps an understandable one. |
|
Maybe it's feature creep, but I think ACS is a nice compliment to replicate with large distributed replica systems. You have one master in one region, then a bunch of replicas in different regions. Using ACS to only pay the cross region penalty once makes sense to have a simplified hierarchy structure and avoid daisy-chaining your upstream pulps. We probably need to do more work on ACS to make it easier to setup and work with replicate, but this first change seems fine to me. |
|
$USER essentially said that they cannot use ACS in the current state regardless, so this PR could be deferred until a broader rethink perhaps. |
3 participants
ACS objects shouldn't prevent Remotes from being deleted. This was primarily an issue with replication, where creation and deletion of remotes is mostly hands-off.
Why CASCADE instead of SET_NULL? the serializer requires one on deletion, and deleting the remote would orphan it (leaving it nonfunctional) anyway, so it seems like the best option?
📜 Checklist
See: Pull Request Walkthrough