Invalid result in many to many list if through instance is soft deleted

Hi guys. I have below models

class BaseModel(SafeDeleteModel):
     _safedelete_policy = SOFT_DELETE_CASCADE
     
class Student(BaseModel):
    full_name = models.CharField(max_length=150)

class School(BaseModel):
    name = models.CharField(max_length=150)
    students = models.ManyToManyField(
        Student,
        through='SchoolStudent',
    )

class SchoolStudent(BaseModel):
    student = models.ForeignKey(Student, on_delete=models.CASCADE)
    school = models.ForeignKey(School, on_delete=models.CASCADE)

I create a relationship between a school and a student, and then I delete it. but the below event occurs

school = School.objects.create(name='new_school')
student = Student.objects.create(full_name='Tom Smith')
school.students.add(student)
# delete all relationship
SchoolStudent.objects.all().delete()

school.students.all()

<QuerySet [<Student: Tom Smith>]>

As you see. we get wrong results. we deleted the relationship but we get the queryset. Have you got any idea to solve the issue?

[bjudson]

I’m seeing this same issue with 1.1.0. I actually was working on my own soft delete implementation and this was one of the issues that led me to start looking at 3rd party libraries. What I’ve found is that RelatedManager inherits the way you’d expect, but ManyRelatedManager does not. So you’ll find with an example like above:

school.students.count()  # returns 1
school.schoolstudent_set.count()  # returns 0

Thanks for your response. It worked, but as you know, it returns the SchoolStudent entities. but I need student entities.

Correct. As a workaround for your situation, you can just do something like:

Student.objects.filter(schoolstudent__school=school, schoolstudent__deleted=None)

But it will be difficult to remember not to use ManyRelatedManager with these objects, and likely lead to bugs at some point.

I’ll keep looking at this and see if I can find any solution, and if so submit a PR. I decided to adopt this library in a project I’m working on, largely because of its strong tests and handling of tricky situations like this, so I’d love to have this one handled in an intuitive way.

Thanks for your work & responsiveness @Gagaro

[Gagaro]

So because create_forward_many_to_many_manager() create a new manager inheriting from our own and not the other way around, it seems complicated to fix this.

I added a test which reproduce this but it fails for now.