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

Fix really_destroy used against a has_one relationship that is soft deleted #574

Open
wants to merge 2 commits into
base: core
Choose a base branch
from

Conversation

reedstonefood
Copy link
Contributor

I found a bug. The test explains the scenario but I'll explain it here as well.

Given:

class MyModel < ActiveRecord::Base
  acts_as_paranoid
  has_one: linked_model, dependant: destroy
end

class LinkedModel < ActiveRecord::Base
  acts_as_paranoid
end

my_model = MyModel.create!(linked_model: LinkedModel.new)
  • ✅ If you run my_model.destroy then both objects get soft-deleted as you would expect
  • ❌ However if you then subsequently run my_model.really_destroy it does not destroy the associated linked_model.

This is because paranoia tries to access the linked model by running self.send(name). This command will not pick up soft-deleted has_one associations (though it works fine for has_many associations) so some extra code is required in this scenario.

Note the reload in the test is required, as otherwise the version of my_model in memory still links to the LinkedModel.

@reedstonefood
Copy link
Contributor Author

@mathieujobin any chance you could have a look at this please?

@reedstonefood
Copy link
Contributor Author

FYI the test failures on rails versions older than 7.1 are nothing to do with the changes in this MR, they are a wider issue that is detailed here: https://stackoverflow.com/questions/79360526/uninitialized-constant-activesupportloggerthreadsafelevellogger-nameerror

@reedstonefood
Copy link
Contributor Author

I've just spotted that this looks like a duplicate of #428, but as I'm actively engaged about this MR and it has working tests, it probably makes sense to progress with this one.

@@ -182,6 +182,9 @@ def really_destroy!(update_destroy_attributes: true)
association_data = self.send(name)
# has_one association can return nil
# .paranoid? will work for both instances and classes
if association_data.nil? && reflection.has_one? && reflection.klass.paranoid?
association_data = reflection.klass.only_deleted.find_by(reflection.foreign_key => self.id)
end
Copy link
Collaborator

Choose a reason for hiding this comment

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

@yoheimuta Can you chime in about this change?

Copy link
Contributor

Choose a reason for hiding this comment

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

@mathieujobin Looks good to me! 👍

[nits] For has_one associations that are polymorphic (foreign_type column exists), find_by should also filter by foreign_type to avoid fetching unrelated records.

Suggested improvement:

query = { reflection.foreign_key => self.id }
query[reflection.type] = self.class.name if reflection.options[:as] # Handle polymorphic associations
association_data = reflection.klass.only_deleted.find_by(query)

This ensures we correctly match records when dealing with polymorphic has_one associations.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@reedstonefood Can you review this suggestion, see if that matches with your use case, etc.

thanks

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This change works with the test suite here & in the product I'm working on, so LGTM.

I've also managed to add another test that fails without this change in place 👍 .

@mathieujobin
Copy link
Collaborator

is it possible to fix the tests for older version in this PR or in a different PR ?

@reedstonefood
Copy link
Contributor Author

is it possible to fix the tests for older version in this PR or in a different PR ?

I've raised #576 for this.

@reedstonefood reedstonefood force-pushed the really-destroy-has-one-already-soft-deleted branch from 181519b to 16ebd82 Compare March 17, 2025 09:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants