Wie würden Sie ein Revisionskontrollsystem für Ihre Modelle in Ihrem bevorzugten db-Paradigma implementieren?

Question

Ich fand heraus, dass RCS für Modelle ein interessantes Problem im Zusammenhang mit Datenpersistenz zu lösen ist. Sie sind mehrere Lösung mit dem Django ORM, um diese django-reversion und AuditTrail zu erreichen, von denen jede ihren eigenen Weg, um es zu tun.

Hier ist das Modell (in django-Modell-like-Format), die ich Revisionen haben möchte:

class Page(Model): 

    title = CharField() 
    content = TextField() 
    tags = ManyToMany(Tag) 
    authors = ManyToMany(Author) 

• Jede Revision mit einem Datum, eine Revisionsnummer mit Anmerkungen versehen werden soll , ein Kommentar und der Benutzer, die die Änderung vorgenommen hat.

Wie würden Sie es in Ihrem bevorzugten db (Mongo, neo4j, CouchDb, GAE Datastore) tun?

Bitte veröffentlichen Sie nur ein Beispiel RCS-Modelle per Post.

Ich frage nicht nach einem vollständigen Code (vielleicht ist eine Erklärung genug?) Aber genug, um zu sehen, wie dieses Problem in jedem DB-Typ angegangen werden kann.

Answer 1

In CouchDB ist dies ziemlich einfach. Jedes Element in der DB hat eine _id und eine _rev. Sie benötigen also keine separate Revisionsnummer. Ich würde das wahrscheinlich dann tun. Weisen Sie jedem Artikel eine Systemrev-Nummer zu. Diese Nummer wäre eine Verknüpfung zu einem anderen DB-Datensatz, der das Datum, den Kommentar und den Benutzer für diese Revision enthält.

Beispiele:

Artikel verfolgt werden:

{ 
    _id: "1231223klkj123", 
    _rev: "4-1231223klkj123", 
    systemRev: "192hjk8fhkj123", 
    foo: "bar", 
    fooarray: ["bar1", "bar2", bar3"] 
} 

Und dann eine separate Revision Datensatz erstellen:

{ 
    _id: "192hjk8fhkj123", 
    _rev: "2-192hjk8fhkj123", 
    user: "John", 
    comment: "What I did yesterday", 
    date: "1/1/2010", 
    tags: ["C# edits", "bug fixes"] 
} 

Für mich ist es ziemlich elegant scheint ....

Answer 2

Wenn Sie CouchDB verwenden, verwenden Sie nicht das Feld _rev.

Warum? Alte Revisionen gehen verloren, wenn eine Datenbank komprimiert wird.

Verdichtungs schreibt die Datenbankdatei, veraltete Dokumentversionen zu entfernen und gelöschte Dokumente.

CouchDB wiki - Compaction page

Es gibt ein paar mögliche Lösungen:

1. Halten Sie aktuelle und alte Versionen in derselben Datenbank. Fügen Sie ein zusätzliches Revisionsfeld hinzu, um den Unterschied zwischen aktuellen und alten Revisionen zu ermitteln.
2. Alte Revisionen in einer separaten Datenbank speichern.Wenn eine neue Revision zur "aktuellen" Datenbank hinzugefügt wird, kann das alte Revisionsdokument gelöscht und in die Datenbank "Revisionen" eingefügt werden.

Welches ist das beste? Es hängt davon ab, wie auf Ihre Daten zugegriffen wird. Wenn Sie die alten Revisionen unabhängig von den aktuellen Revisionen abfragen können, bietet das Speichern des Dokuments in zwei verschiedenen Datenbanken einige Leistungsvorteile.