"Schema" in Ravendb ändern

Question

Nur um mein Wissen zu erweitern, habe ich begonnen, verschiedene NoSQL -Optionen zu betrachten. Der erste, den ich besuchte, ist Ravendb und es sieht interessant aus. Ich versuche immer noch, mein tiefsitzendes relationales Denken zusammen mit den typischen RDBMS-Wartungsroutinen zu brechen.

In meinem täglichen Umgang mit Entity-Framework durchlaufen wir die Routine von Skript-DB-Änderungen, erfrischen das EF-Mapping-Modell usw. Wie funktioniert es in NoSQL-Sachen, insbesondere in Ravendb? Sobald eine App das Leben gegangen ist, wie nimmt man Änderungen an den verschiedenen PoCO -Objekten usw. vor und bereitet sie für die Produktion ein? Was passiert mit Daten, die in den alten POCO -Klassen gespeichert sind?

Ich habe mich noch nicht in Wut verprügelt oder Raven DB verwendet. Dies mag offensichtlich sein, sobald ich es tue, würde es aber gerne vor der Hand wissen, damit ich mich nicht in eine Ecke codiert.

Danke: D.

Answer 1

Sie bleiben so, wie sie sind - Eigenschaften, die nicht mehr existieren, werden beim Laden (und beim Veränderung verloren) ignoriert, und fehlende Eigenschaften werden als Null zurückkommen.

Empfehlen Sie, Sie setzbasierte Vorgänge zu verwenden, um die Daten mit dem Objektmodell zu unterbinden.

Oh, schau mich an, ich bin jetzt auf einem Computer!

Richtig, im Grunde genommen können Sie bei der Überstellung in einen Dokumentgeschäft zu Recht erkennen, dass Sie einige Funktionen verlieren und in einer Datenbank einige Freiheit erlangen, dass Sie ein Vorabschema definiert haben, und versuchen, Daten hochzuladen, die nicht mit diesem Schema übereinstimmen werden werden werden. zu einem Fehler führen.

Es ist jedoch wichtig zu erkennen, dass es einen Unterschied zwischen Schema und ohne strukturell gibt, da Ihre Dokumente alle ihre eigene Struktur enthalten (Schlüssel-/Wertpaare, die den Namensnamen und den Eigenschaftswert des Eigenschaft bezeichnen).

Dies ist nützlich für das gesamte "Just Geting On" -Faktor des Schreibens von Code und das Fortbestehen Ihrer Daten - aber wenn Sie so einfach sind, Ihre Codestruktur zu ändern, kann es schwieriger sein, diese mit Ihren bereits anhaltenden Daten in Einklang zu bringen.

Zu diesem Zeitpunkt präsentieren sich einige Strategien:

• Machen Sie Ihre Struktur unveränderlich, sobald Sie anhaltende Daten haben, Version Ihrer Klassen
• Ermöglichen Sie eine Änderung der Struktur, verwenden Sie jedoch set-basierte Vorgänge, um Daten so zu aktualisieren, dass sie eine neue Struktur entsprechen
• Ermöglichen Sie eine Änderung der Struktur und schreiben Sie Code, um beim Laden von Daten mit Inkonsistenzen umzugehen

Die dritte ist eindeutig eine schlechte Idee, da er zu nicht abholfenem Code führt. Die Versionierung Ihrer Klassen kann funktionieren, wenn Sie nur Ereignisse oder andere solche Daten speichern, aber für die meisten Szenarien nicht wirklich geeignet sind, sodass Sie mit der Mitte übrig sind Möglichkeit.

Ich würde genau das empfehlen und ein paar einfachen Regeln in der gleichen Richtung wie Sie bei der Bearbeitung eines Vorabschemas in einer relationalen Datenbank folgen würden.

• Verwenden Sie Ihr VCS -System, um Änderungen zwischen bereitgestellten Versionen zu bestimmen
• Schreiben Sie Migrationsskripte, die von einer Version auf eine andere aktualisieren
• Achten Sie auf die Umbennen/Entfernen von Eigenschaften - Wenn Sie ein Dokument geladen und das Dokument speichern

Usw.

Ich hoffe das ist hilfreicher :-)

Answer 2

Ravendb serialisiert Ihre .NET -Objekte in das JSON -Format. Es gibt kein Schema.

Wenn Sie Ihrer Datenbank einige Objekte hinzufügen, werden sie serialisiert. Wenn Sie dem serialisierenden Typ einige Eigenschaften hinzufügen, fehlen die von Ihnen bereits gespeicherten Objekte diese Eigenschaften.

Answer 3

In diesem Artikel von Ayende wird beschrieben, wie eine Migration von 1 zu Version 2 durchgeführt wird (in diesem Fall eine Eigenschaften "FirstName" und "LastName" -Reopie "Name" in "FirstName" und "Lastname".

http://ayende.com/blog/66563/ravendb-migrations-rolling-Updates

Grundsätzlich ist ein Hörer im DocumentStore registriert:

documentStore.RegisterListener(new CustomerVersion1ToVersion2Converter())

Beispielimpementation aus dem oben genannten Artikel:

public class CustomerVersion1ToVersion2Converter : IDocumentConversionListener
{
    public void EntityToDocument(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;

        metadata["Customer-Schema-Version"] = 2;
        // preserve the old Name property, for now.
        document["Name"] = c.FirstName + " " + c.LastName;
        document["Email"] = c.CustomerEmail;
    }

    public void DocumentToEntity(object entity, RavenJObject document, RavenJObject metadata)
    {
        Customer c = entity as Customer;
        if (c == null)
            return;
        if (metadata.Value<int>("Customer-Schema-Version") >= 2)
            return;

        c.FirstName = document.Value<string>("Name").Split().First();
        c.LastName = document.Value<string>("Name").Split().Last();
        c.CustomerEmail = document.Value<string>("Email");
    }
}

Answer 4

Sie haben nicht so viel Schema -Management, da Sie ihn in Ihren Code verschieben, sodass zwischen den Objekten in Ihrem Code und denen in Ihrer Datenbank nie eine Nichtübereinstimmung zwischen den Objekten besteht.

Der erste Teil der Änderungen der Handhabung besteht darin, sicherzustellen, dass Sie einen Serializer verwenden, der fehlende/zusätzliche Werte verarbeiten kann. Wenn ein Feld nicht in den Daten definiert ist, setzen Sie ihn auf null. Wenn ein Feld in den Daten nicht mit einer Eigenschaft in Ihrem Objekt übereinstimmt, ignorieren Sie es.

Die meisten Änderungen können ohne das behandelt werden - entweder gibt es ein neues Feld und Sie müssen ohnehin einen Standardwert für vorhandene Datensätze haben, oder es gibt ein altes Feld, das Sie sich nicht mehr interessieren.

Für komplexere Änderungen wie Umbenennen/Kombinieren von Feldern oder das Ändern von Datenformat fügen Sie Ihrem Objekt ein neues Feld hinzu, ohne die alten zu entfernen und Ihre Lastmethodenübertragungsdaten von den alten Feldern zu übertragen. Wenn Sie den Datensatz speichern, befindet sich dies im neuen Format. Dieser Code kann entweder dauerhaft vorhanden sein und Daten nach Bedarf aktualisieren, oder Sie können einen einmaligen Prozess einrichten, um denselben Code für alle vorhandenen Objekte aufzurufen. Beachten Sie, dass im Gegensatz zu einem SQL -Skript keine Ausfallzeit für diese Art von Aktualisierung erforderlich ist, auch wenn es lange dauert, bis es auf einem großen Datensatz ausgeführt wird, da der Code sowohl alte als auch neue Formate verarbeiten kann.