Feldpräsenz bei Protocol Buffers: das Setzen auf null vom Belassen eines Felds unterscheiden

Worum es geht

Der Hinweis von Protocol Buffers zur Feldpräsenz unterscheidet implizite und explizite Präsenz. Bei impliziter Präsenz tragen skalare Felder mit Standardwert nicht denselben expliziten Gesetzt-Zustand, und Standardwerte werden vom dokumentierten Merge-Verhalten übersprungen. Explizite Präsenz kann ein Feld darstellen, das absichtlich auf seinen Standardwert gesetzt wurde. Das ist relevant, wenn eine Nachricht zugleich als partielle Aktualisierungsanfrage dient. Protocol Buffers: Feldpräsenz

Warum es wichtig ist

Ein Agent interpretiert null möglicherweise als "keine Aktualisierung" und verhindert dadurch versehentlich, dass ein Client einen Zähler zurücksetzt oder eine Einstellung deaktiviert. Eine andere Implementierung überschreibt einen bestehenden Wert möglicherweise mit einem Standardwert, nur weil das Feld weggelassen wurde. Die Aktualisierungsabsicht getrennt vom skalaren Wert selbst definieren.

So wird es angewendet

• Für jedes Aktualisierungsfeld die Bedeutung von fehlend, vorhanden mit einem Wert ungleich dem Standardwert und vorhanden mit dem Standardwert festhalten. Lösch- oder Reset-Semantik explizit einbeziehen.
• Eine Schemadarstellung wählen, die diese Zustände ausdrückt, etwa explizite Präsenz, wo unterstützt, oder eine dokumentierte Update-Maske. Nicht annehmen, dass allein der generierte Getter zeigt, ob ein Wert geliefert wurde.
• Die Anfrage durch jeden Zwischenschritt und jede Merge-Operation nachverfolgen. Prüfen, dass eine ältere teilnehmende Komponente oder eine Serialisierungsumwandlung nicht Präsenzinformationen verwirft, die der Aktualisierungsvertrag benötigt.
• Testfälle vorschlagen, die von einem gespeicherten Wert ungleich dem Standardwert ausgehen: das Feld weglassen, einen anderen Wert ungleich dem Standardwert setzen und den Standardwert explizit setzen. Unterschiedliche Ergebnisse prüfen, wo der Vertrag sie verlangt.
• Die Testfälle über den tatsächlichen öffentlichen Transportweg und die generierte Sprach-API wiederholen. Syntax oder Edition sowie die beteiligten Laufzeitversionen auf diesem Pfad dokumentieren.

Stolpersteine

Wire-Kompatibilität stellt nicht sicher, dass die Aktualisierungsabsicht der Anwendung erhalten bleibt. Repeated-Felder, Maps und Message-Felder haben ihr eigenes Präsenzverhalten und sollten nicht mechanisch die Regeln für Skalare übernehmen. Eine Update-Maske muss zudem gegen das tatsächliche Anfrageschema validiert werden. Dieser Artikel schlägt einen Vertrag und Prüfplan für partielle Aktualisierungen vor; er behauptet keinen ausgeführten Interoperabilitätstest über gemischte Versionen hinweg.