Add latest changes from gitlab-org/gitlab@master

2 files changed, 14 insertions, 4 deletions

diff --git a/doc/development/database/loose_foreign_keys.md b/doc/development/database/loose_foreign_keys.md
index d08e90683fe..9a44198d908 100644
--- a/doc/development/database/loose_foreign_keys.md
+++ b/doc/development/database/loose_foreign_keys.md
@@ -234,6 +234,12 @@ We considered using these Rails features as an alternative to foreign keys but t
 1. These can lead to severe performance degradation as we load all records from PostgreSQL, loop over them in Ruby, and call individual `DELETE` queries.
 1. These can miss data as they only cover the case when the `destroy` method is called directly on the model. There are other cases including `delete_all` and cascading deletes from another parent table that could mean these are missed.
 
+For non-trivial objects that need to clean up data outside the
+database (for example, object storage) where you might wish to use `dependent: :destroy`,
+see alternatives in
+[Avoid `dependent: :nullify` and `dependent: :destroy` across
+databases](./multiple_databases.md#avoid-dependent-nullify-and-dependent-destroy-across-databases).
+
 ## Risks of loose foreign keys and possible mitigations
 
 In general, the loose foreign keys architecture is eventually consistent and
diff --git a/doc/development/database/multiple_databases.md b/doc/development/database/multiple_databases.md
index 1338e83070f..1ca2874837f 100644
--- a/doc/development/database/multiple_databases.md
+++ b/doc/development/database/multiple_databases.md
@@ -623,10 +623,14 @@ outcomes when we switch to decomposed, because now you have some queries
 happening outside the transaction and they may be partially applied while the
 outer transaction fails, which could lead to surprising bugs.
 
-If you need to do some cleanup after a `destroy` you will need to choose
-from some of the options above. If all you need to do is cleanup the child
-records themselves from PostgreSQL then you could consider using ["loose foreign
-keys"](loose_foreign_keys.md).
+For non-trivial objects that need to clean up data outside the
+database (for example, object storage), we recommend the setting
+[`dependent: :restrict_with_error`](https://guides.rubyonrails.org/association_basics.html#options-for-has-one-dependent).
+Such objects should be removed explicitly ahead of time. Using `dependent: :restrict_with_error`
+ensures that we forbid destroying the parent object if something is not cleaned up.
+
+If all you need to do is clean up the child records themselves from PostgreSQL,
+consider using [loose foreign keys](loose_foreign_keys.md).
 
 ## `config/database.yml`