From Jonathan Green in comments to the PR https://github.com/NYPL-Simplified/server_core/pull/1236:

I did a little testing in the UI to see how deletes cascade to see if this will leave any configuration settings around that would have been legitimately deleted before and here is what I found:

Test setup

• New CM for testing
• Add a library
• Add a overdrive collection and add that collection to the library

I started fresh and performed that setup before conducting each of these tests:

1. Disassociate the library from the collection
2. Delete the library
3. Delete the collection, then run database_reaper

Look at the settings left in the configurationsettings table after each step. With both the new and the old code, the results were the same, so I don't think these results should hold up this PR.

I was a bit surprised by the results though, so maybe another ticket is in order to make sure that configurationsettings get cleaned up if they are no longer needed.

1. Disassociate the library from the collection

After this the configurationsettings referencing the library and externalintegrations for the collection were still in the table, but their values were set to null.

1. Delete the library

All the configurationsettings referencing the library are removed.

1. Delete the collection, then run database_reaper

All of the configurationsettings and externalintegrations for the collection remain in the database, even though the collection itself is removed.

#1 and #3 might pose a problem since we're adding a uniqueness constraint on this table that applies when values are null. People might especially run into problems if they delete a collection and then try to recreate it.