Verhindern, löschen Sie in der Django-Modell

War ich auf der Suche nach einer Antwort auf dieses problem, war nicht in der Lage, einen guten finden, das funktioniert für beide Modelle.Modell.delete() und QuerySet.löschen(). Ich ging zusammen und, irgendwie, Durchführung Steve K die Lösung. Ich habe diese Lösung, um sicherzustellen, dass ein Objekt (Mitarbeiter in diesem Beispiel), können nicht aus der Datenbank gelöscht werden, so oder so, aber auf inaktiv gesetzt.

Es ist eine späte Antwort.. nur zum Wohle der anderen Menschen auf der Suche, ich Stelle meine Lösung hier.

Hier ist der code:

class CustomQuerySet(QuerySet):
    def delete(self):
        self.update(active=False)


class ActiveManager(models.Manager):
    def active(self):
        return self.model.objects.filter(active=True)

    def get_queryset(self):
        return CustomQuerySet(self.model, using=self._db)


class Employee(models.Model):
    name = models.CharField(name, unique=True)
    active = models.BooleanField(default=True, editable=False)

    objects = ActiveManager()

    def delete(self):
        self.active = False
        self.save()

Verwendung:

Employee.objects.active() # use it just like you would .all()

oder in den admin:

class Employee(admin.ModelAdmin):

    def queryset(self, request):
        return super(Employee, self).queryset(request).filter(active=True)

InformationsquelleAutor Elwin

Diese würden wrap-up-Lösung aus der Umsetzung meiner app. Einige code-form LWN Antwort.

Gibt es 4 Situationen, dass Ihre Daten gelöscht:

• SQL-Abfrage
• Aufrufen delete() auf Model-Instanz: project.delete()
• Aufrufen delete() auf QuerySet innstance: Project.objects.all().delete()
• Gelöscht ForeignKey-Feld auf ein anderes Modell

Zwar gibt es nichts viel Sie tun können, mit dem ersten Fall, die anderen drei können feinkörnige gesteuert.
Eine Beratung ist, dass in den meisten Fällen, sollten Sie nie löschen Sie die Daten selbst, da diese Daten spiegeln die Geschichte und die Nutzung unserer Anwendung. Einstellung auf active Boolean-Feld ist bevorzugt, statt.

Um zu verhindern, dass delete() auf Model-Instanz, Unterklasse delete() im Modell-Erklärung:

    def delete(self):
        self.active = False
        self.save(update_fields=('active',))

Während delete() auf QuerySet-Instanz muss ein kleines setup mit einem benutzerdefinierten Objekt-manager wie in LWN Antwort.

Wickeln diese bis zu einer wiederverwendbaren Implementierung:

class ActiveQuerySet(models.QuerySet):
    def delete(self):
        self.save(update_fields=('active',))


class ActiveManager(models.Manager):
    def active(self):
        return self.model.objects.filter(active=True)

    def get_queryset(self):
        return ActiveQuerySet(self.model, using=self._db)


class ActiveModel(models.Model):
    """ Use `active` state of model instead of delete it
    """
    active = models.BooleanField(default=True, editable=False)
    class Meta:
        abstract = True

    def delete(self):
        self.active = False
        self.save()

    objects = ActiveManager()

Nutzung, nur Unterklasse ActiveModel Klasse:

class Project(ActiveModel):
    ...

Immer noch unser Objekt können noch gelöscht werden, wenn irgendeiner Ihrer ForeignKey Felder gelöscht:

class Employee(models.Model):
    name = models.CharField(name, unique=True)

class Project(models.Model):
    name = models.CharField(name, unique=True)
    manager = purchaser = models.ForeignKey(
        Employee, related_name='project_as_manager')

>>> manager.delete() # this would cause `project` deleted as well

Dies kann verhindert werden durch Zugabe von on_delete argument von Modell field:

class Project(models.Model):
    name = models.CharField(name, unique=True)
    manager = purchaser = models.ForeignKey(
        Employee, related_name='project_as_manager',
        on_delete=models.PROTECT)

Standardwert on_delete ist CASCADE wodurch wird die Instanz gelöscht, indem PROTECT statt, die heben einen ProtectedError (eine Unterklasse von IntegrityError). Ein weiterer Zweck ist, dass der ForeignKey-Daten gehalten werden sollten als Referenz.

InformationsquelleAutor anhdat

Ich würde gerne vorschlagen, eine weitere variation auf LWN und anhdat ist Antworten, worin wir verwenden eine deleted - Feld statt ein active Feld und wir schließen die "gelöschten" Objekte aus der Standard-queryset, so behandeln Sie diese Objekte als nicht mehr vorhanden, es sei denn, wir spezifisch sind.

class SoftDeleteQuerySet(models.QuerySet):
    def delete(self):
        self.update(deleted=True)


class SoftDeleteManager(models.Manager):
    use_for_related_fields = True

    def with_deleted(self):
        return SoftDeleteQuerySet(self.model, using=self._db)

    def deleted(self):
        return self.with_deleted().filter(deleted=True)

    def get_queryset(self):
        return self.with_deleted().exclude(deleted=True)


class SoftDeleteModel(models.Model):
    """ 
    Sets `deleted` state of model instead of deleting it
    """
    deleted = models.NullBooleanField(editable=False)  # NullBooleanField for faster migrations with Postgres if changing existing models
    class Meta:
        abstract = True

    def delete(self):
        self.deleted = True
        self.save()

    objects = SoftDeleteManager()


class Employee(SoftDeleteModel):
    ...

Verwendung:

Employee.objects.all()           # will only return objects that haven't been 'deleted'
Employee.objects.with_deleted()  # gives you all, including deleted
Employee.objects.deleted()       # gives you only deleted objects

Wie gesagt in anhdat Antwort, stellen Sie sicher, dass die on_delete Eigenschaft auf ForeignKeys auf Ihrem Modell zu vermeiden, cascade-Verhalten, z.B.

class Employee(SoftDeleteModel):
    latest_project = models.ForeignKey(Project, on_delete=models.PROTECT)

Hinweis:

Ähnlicher Funktionalität ist enthalten in django-Modell-utils's SoftDeletableModel wie ich gerade entdeckt. Wert heraus überprüfen. Kommt mit einigen anderen praktischen Dinge.

InformationsquelleAutor Felix Böhme