Bitte helfen Sie mir, die Abwärtskompatibilität und die Erweiterbarkeit der internen Implementierung der Protokollpuffer zu verstehen.
Wie wird die Rückwärtskompatibilität beim Löschen von Datenfeldern erreicht? Ich stelle mir vor, dass der generierte Datenzugriffscode leere Werte für Eigenschaften zurückgibt, die nicht im Datenstrom vorhanden sind, und der Verbrauchercode muss immer speziell nach diesen leeren Werten suchen und entsprechend handeln. Wie würden die leeren Werte standardisiert werden?
Wie weiß der alte Code auch in diesem Fall, dass die Eigenschaft nicht mehr im Datenstrom vorhanden ist?
Ich stelle mir vor, dass eine Lösung darin besteht, dass alte Daten niemals aus der internen Stream-Spezifikation gelöscht und nur durch leere Werte ersetzt werden, aber das gleiche könnte wahrscheinlich durch interne Versionierung der Felder erreicht werden.
Vielleicht eine klarere Frage: Wie kann der alte Code neue Daten ignorieren, die von neuen Versionen der .proto-Spezifikation hinzugefügt wurden? Dies ist wahrscheinlich etwas einfacher als 1), indem Sie ein Größenfeld in der internen serialisierten Struktur haben und nur so viele Bytes gleichzeitig lesen, während Sie auch nur neue Felder am Ende der Struktur anhängen.
Versuchen Sie, all dies zu verstehen, um ein altes Datenformat zu erweitern, um die Rückwärts- / Vorwärts-Kompatibilität zwischen Code und Daten als Nebenprojekt bereitzustellen.
Bearbeiten: Formatieren.
Danke!
Einige Hintergrundinformationen, In Protokollpuffern definieren Sie ein Feld wie
%Vor%Die Nummer ( 1 in diesem Beispiel ) wird verwendet, um das Feld in der Data-Message (oder Data-Record) und für die Übereinstimmung mit der verwendeten Proto-Nachricht zu identifizieren von Ihrem Programm.
Protokollpuffer speichern Daten wie
%Vor%Wobei fieldId aus der Feldnummer und dem Feldtyp besteht. Wenn ein Feld keine Daten enthält, wird nicht in der Ausgabenachricht (Datensatz) gespeichert. Sie können also
haben %Vor%Antworten auf Ihre Fragen:
In Protokollpuffern hat jedes Feld ein Attribut dieser Attribute: Erforderlich , Optional und Wiederholt . Um also ein Feld löschen zu löschen, können Sie es optional machen und keinen Wert darin speichern. Manche Leute machen routinemäßig die meisten Felder optional
Protokoll Entspricht den Feldnummern in der Datennachricht mit Feldnummern in der Proto-Definition. In Java gibt es mindestens unbekannte Felder Map wo zusätzliche Felder gespeichert sind.
Es ist wichtig, dass Sie Dokumente Felder (sowohl die Feldname als auch Feldnummer ) entfernen, um sicherzustellen, dass Sie haben Verwenden Sie niemals einen Feldnamen / eine Feldnummer .
Wenn Sie ein Feld wiederverwenden, könnten Sie den vorhandenen Code auflösen
Tags und Links serialization protocol-buffers