Wie kann ich Datensätze in Django-Modellen einfach als gelöscht markieren, anstatt sie tatsächlich zu löschen?

Question

Anstatt Datensätze in meiner Django-Anwendung zu löschen, möchte ich sie nur als "gelöscht" markieren und sie vor meinen aktiven Abfragen verbergen. Mein Hauptgrund dafür ist, dem Benutzer eine Undelete-Option zu geben, falls er versehentlich einen Datensatz löscht (diese Datensätze können auch für bestimmte Backend-Überwachungsnachverfolgung erforderlich sein).

Es gibt viele Fremdschlüsselbeziehungen, also wann Ich markiere einen Datensatz als gelöscht. Ich müsste dieses Lösch-Flag auch auf diese Datensätze "kaskadieren". Welche Tools, bestehenden Projekte oder Methoden sollte ich verwenden?

Answer 1

Django bietet Ihnen den genauen Mechanismus, nach dem Sie suchen.

Sie können den Manager ändern, der für den Zugriff über verwandte Objekte verwendet wird. Wenn der neue benutzerdefinierte Manager das Objekt in einem booleschen Feld filtert, wird das als inaktiv markierte Objekt nicht in Ihren Anforderungen angezeigt.

Sehen Sie hier für weitere Informationen: vor http://docs.djangoproject.com/en/dev/topics/db/managers/#using-managers-for-related-object-access

Answer 2

Nette Frage, ich habe mich gefragt, wie man das selbst effizient macht.

Ich bin nicht sicher, ob dies den Trick tun wird, aber django-reversion scheint zu tun, was Sie wollen, obwohl Sie wahrscheinlich untersuchen möchten, um zu sehen, wie es dieses Ziel erreicht, da es einige ineffiziente Möglichkeiten gibt, es zu tun.

Ein anderer Gedanke wäre, die gefürchtete boolesche Flagge auf Ihren Modellen zu haben und dann einen benutzerdefinierten Manager zu erstellen, der den Filter automatisch hinzufügt, obwohl dies nicht für Suchen über verschiedene Modelle hinweg funktionieren würde. Noch eine andere Lösung suggested here ist doppelte Modelle von allem zu haben, was wie Overkill scheint, aber kann für Sie arbeiten. Die Kommentare dort diskutieren auch verschiedene Optionen.

Ich werde hinzufügen, dass in den meisten Fällen halte ich keine dieser Lösungen die Mühe wert; Ich sauge es normalerweise einfach auf und filtere meine Suchen auf der booleschen Flagge. Es vermeidet viele Probleme, die auftreten können, wenn Sie versuchen, zu clever zu werden. Es ist ein Schmerz und nicht sehr trocken, natürlich. Eine vernünftige Lösung wäre eine Mischung aus dem benutzerdefinierten Manager, während Sie sich dessen Beschränkungen bewusst sind, wenn Sie versuchen, ein damit verbundenes Modell zu durchsuchen.

Answer 3

Ich denke, mit einem booleschen "is_active" -Flag ist in Ordnung - Sie müssen nicht die Flagge auf verwandte Einträge auf der Ebene db kaskadieren, müssen Sie nur auf den Status des übergeordneten verweisen. Das passiert mit dem User-Modell von contrib.auth, denken Sie daran - einen Benutzer als nicht zu markieren is_active veranlaßt django nicht, verwandte Modelle zu durchsuchen und magischerweise versuchen, Datensätze zu deaktivieren, sondern einfach das Attribut is_active des entsprechenden Benutzers zu überprüfen verwandte Artikel.

Wenn beispielsweise jeder Benutzer viele Lesezeichen hat und Sie nicht möchten, dass die Lesezeichen eines inaktiven Benutzers sichtbar sind, stellen Sie sicher, dass bookmark.user.is_active wahr ist. Es ist unwahrscheinlich, dass ein is_active Flag auf dem Lesezeichen selbst benötigt wird.

Answer 4

Hier ist eine schnelle Blog-Tutorial von Greg Allard von ein paar Jahren, aber ich setzte es Django 1.3 verwenden und es war großartig. Ich habe Methoden zu meinen Objekten namens soft_delete, undelete und hard_delete hinzugefügt, die self.deleted = True, self.deleted = False gesetzt und self.delete() zurückgegeben haben.

A Django Model Manager for Soft Deleting Records and How to Customize the Django Admin

Answer 5

Es gibt mehrere Pakete, die diese Funktionalität bereitstellen: https://www.djangopackages.com/grids/g/deletion/

Ich bin ein https://github.com/meteozond/django-permanent/ Entwicklung ersetzt es Standard-Manager und QuerySet Methoden löschen in logische Löschung zu bringen. Es überschattet Standard-Django-Löschmethoden vollständig mit einer Ausnahme - markiert Modelle, die von PermanentModel anstelle von Löschen geerbt werden, selbst wenn ihre Löschung durch Relation verursacht wird.