Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: physically delete records from the database on #892

Merged
merged 2 commits into from
Nov 1, 2023

Conversation

pivotal-marcela-campo
Copy link
Member

@pivotal-marcela-campo pivotal-marcela-campo commented Oct 31, 2023

deprovision/unbind

Records where being soft-deleted or not even soft-deleted from the database on deprovision and unbind.
The terraform_deployments table (which was not even being soft-deleted) would accumulate thousands of records over time, making consistency checks very slow and causing cloud foundry to time out on app start up. Although we could work on changing the way the checks are performed, the broker doesn't have any uses for these soft-deleted or old records once the operation has completed successfully. Hence there is no real use at the moment in keeping this data in the database and take over space and affect performance.

#186230750

Checklist:

  • Have you added or updated tests to validate the changed functionality?
  • Have you added Release Notes in the docs repositories?
  • Have you followed the Conventional Commits specification?

deprovision/unbind

Records where being soft-deleted or not even soft-deleted from the
database on deprovision and unbind.
The terraform_deployments table (which was not even being soft-deleted)
would accumulate thousands of records over time, making consistency
checks very slow and causing cloud foundry to time out on app start up.
Although we could work on changing the way the checks are performed, the
broker doesn't have any uses for these soft-deleted or old records once
the operation has completed successfully. Hence there is no real use at
the moment in keeping this data in the database and take over
space and affect performance.

[#186230750](https://www.pivotaltracker.com/story/show/186230750)
Copy link
Member

@blgm blgm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. An improvement for the future would be to use actual relationships with the data so that we can make use of the database doing a cascade delete. It feels like we are writing code here that's already implemented in the database, and I think that's the right thing to do in the short term, but in the long term we can refactor and reduce the amount of code that we need to maintain.

internal/storage/provision_request_details_test.go Outdated Show resolved Hide resolved
@pivotal-marcela-campo pivotal-marcela-campo merged commit 7e37ff5 into main Nov 1, 2023
6 checks passed
@pivotal-marcela-campo pivotal-marcela-campo deleted the delete-data-physically branch March 22, 2024 11:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

2 participants