# Removing Remotes Safely

## Goals

* A user can delete a remote.
* [mdellweg] When deleting, my credentials need to leave the database altogether.
* A user can delete a remote without having side effects on content.
* [mdellweg] A user can delete a remote without having side effects on distributions.

## Current objects with FK to Remote

* Repository
* RemoteArtifact
* Distributions
* ACS ( already has on_delete PROTECT)

## Strategy

* Let's look at the usages of Remotes and when its unsafe to delete a Remote don't allow it to happen.
* Let's be helpful to the database by provided comprehensive validation

## Proposals

* If a Distribution has a FK to a Remote, prevent Remote deletion. It's in use that's unavoidable.
* If a Repository has a FK to a Remote, prevent Remote deletion. It's in use that's unavoidable. It will also protect all the remote artifacts that are synced into that repository as long as the user only uses the simple sync [95% solution]
* Add the remote to the repository version that used it for synching and prevent deletion. This will protect all RA that were created by that sync.
* Downloader rewrite - have the downloader become picklable, on RA creation have the current state of the Remote create a downloader state and save that to the RA. RA now does not require Remote relation to perform on-demand download. If remote still exists when downloading on-demand use current state of Remote to create the downloader, else use the saved downloader state on RA creation.
*

#### Scenario 1:
* User A and User B both create a remote pointing to the same content.
* User A and User B both sync from the remote using on_demand policy.
* User B decides to remove their remote.
* Removes repository.
* Runs orphan cleanup.
* Content used by User A is not removed.

## Gerrod's comment rewritten

From my comment I think we are going to need to add additional logic to the remote deletion task.

Gather all RemoteArtifacts for Remote and their associated ContentArtifacts
If each ContentArtifact has an Artifact (the content is no longer on-demand), delete all RemoteArtifacts and delete Remote, finished.
Sort each on-demand content-artifact into buckets:
(a) Orphaned and only this one RemoteArtifact
(b) Orphaned and multiple RemoteArtifacts
(c) Non-orphaned
If only items in bucket (a): delete the Remote and the RemoteArtifact, finished.
If only items in bucket (a) & (b): delete each remote artifact,then delete the Remote, finished.
If any items in bucket (c), fail the task. I think if we are in this scenario the logic becomes even more complicated and I don't know if we can safely delete the remote.

I tried to summarized the discussion I had with @dkliban and @ggainey about the new logic needed, but correct me if I forgot or got a part wrong.

## Scratchpad

Any object that has a FK to Remote use `PROTECT` (or maybe `RESTRICT`)