-
Notifications
You must be signed in to change notification settings - Fork 532
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
base: core
Are you sure you want to change the base?
Fix really_destroy used against a has_one relationship that is soft deleted #574
Conversation
@mathieujobin any chance you could have a look at this please? |
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 |
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 👍 .
is it possible to fix the tests for older version in this PR or in a different PR ? |
I've raised #576 for this. |
181519b
to
16ebd82
Compare
I found a bug. The test explains the scenario but I'll explain it here as well.
Given:
my_model.destroy
then both objects get soft-deleted as you would expectmy_model.really_destroy
it does not destroy the associatedlinked_model
.This is because paranoia tries to access the linked model by running
self.send(name)
. This command will not pick up soft-deletedhas_one
associations (though it works fine forhas_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 theLinkedModel
.