Comment tampon protocole de poignée de contrôle de version?

Comment tampons de protocole, de gérer le type de versioning?

Par exemple, quand j'ai besoin de modifier une définition de type fil du temps? Comme l'ajout et la suppression de champs.

InformationsquelleAutor CodingHero | 2011-12-15
  1. 23

    Google conçu protobuf être assez indulgent avec gestion des versions:

    • inattendu données sont stockées comme des "extensions" (ce qui en fait l'aller-retour de sécurité), ou ignoré, en fonction de la mise en œuvre
    • de nouveaux champs sont généralement ajouté en tant que "facultatif", ce qui signifie que les anciennes données peuvent être chargées avec succès

    cependant:

    • ne pas renuméroter champs - qui briserait les données existantes
    • vous ne devrait normalement pas changer la façon dont tout le champ est stocké (c'est à dire à partir d'un fixe avec 32-bit int "varint")

    Généralement parlant, si - il travail juste, et vous n'avez pas besoin de vous soucier de la gestion des versions.

    • Sans doute, la suppression obligatoire les champs de conduit également à des problèmes?
    • si la transmission des données à un client qui a toujours pensé que nécessaire
    • pouvez vous me donner un exemple de manipulation des versions de protobuf
    • Gestion des versions serait une puissante fonctionnalité qui manque à la fois de Google protocole de tampon et de l'Épargne. Je pense que cette réponse est de parler d'un concept différent (tolérance aux erreurs de paramètre) que le type de contrôle de version.
    • vous êtes mieux de ne pas avoir tous les champs définit comme étant "nécessaire" pour cette raison. Cette question est discutée dans le proto de la mémoire tampon de la documentation.
    • Non, vous avez manqué le point. ProtoBuf a été conçu en premier lieu pour prévenir version de l'API de vérification: developers.google.com/protocol-buffers/docs/...
    • Je comprends le raisonnement, mais je ne suis pas sûr que je suis d'accord. Avec la gestion des versions, et pas seulement les nouveaux champs peuvent être mis en place, mais les vieux champs peuvent être obsolète ainsi de manière propre, et ce n'est pas un proto. Proto3 a supprimé "nécessaire" pour cette raison précise, car ils sont source de confusion et risqué de modifier sans le concept de contrôle de version (stackoverflow.com/questions/31801257/...). L'auto-description de format peut aussi être fait avec la gestion des versions, de sorte que je ne la considérons pas comme une force de la protobuf.
    • Je comprends votre point de vue. Je ne l'appelez pas une force ou une faiblesse. C'est juste une décision de conception, nous avons à comprendre et à vivre avec 🙂

    InformationsquelleAutor Marc Gravell
  2. 6

    Je sais que c'est une vieille question, mais je suis tombé sur cette récemment. La façon dont je me suis autour, c'est à l'aide de façades et de l'exécution des décisions en temps pour sérialiser. De cette façon, je peux railler/mise à niveau d'un champ dans un nouveau type, avec les anciens et les nouveaux messages de la manipulation gracieusement.

    Je suis à l'aide de Marc Gravel de l'protobuf.net (v2.3.5), et de C#, mais la théorie de façades fonctionne pour n'importe quelle langue et Google originale de protobuf mise en œuvre.

    Mon ancienne classe avait un Horodatage de DateTime dont je voulais changer pour inclure le "Genre" (un .NET anachronisme). L'ajout de ce qui signifiait qu'il sérialisé à 9 octets au lieu de 8, ce qui serait une rupture de sérialisation changer!

        [ProtoMember(3, Name = "Timestamp")]
    public DateTime Timestamp { get; set; }

    Fondamental de protobuf est de ne JAMAIS changer le proto id! Je voulais lire les anciens sérialisé binaires, ce qui signifiait "3" était là pour rester.

    Donc,

    J'ai renommé le vieux de la propriété et il privé (oui, il peut encore désérialiser par la réflexion de la magie), mais mon API ne s'affiche plus, il utilisable!

        [ProtoMember(3, Name = "Timestamp-v1")]
    private DateTime __Timestamp_v1 = DateTime.MinValue;

    J'ai créé un nouveau Timestamp de la propriété, avec un nouveau proto id, et inclus DateTime.Genre

        [ProtoMember(30002, Name = "Timestamp", DataFormat = ProtoBuf.DataFormat.WellKnown)]
    public DateTime Timestamp { get; set; }

    J'ai ajouté un "AfterDeserialization" méthode de mise à jour de nos nouvelles de temps, dans le cas de vieux messages

        [ProtoAfterDeserialization]
    private void AfterDeserialization()
    {
        //V2 Timestamp includes a "kind" - we will stop using __Timestamp - so keep it up to date
        if (__Timestamp_v1 != DateTime.MinValue)
        {
            //Assume the timestamp was in UTC - as it was...
            Timestamp = new DateTime(__Timestamp_v1.Ticks, DateTimeKind.Utc)     //This is for old messages - we'll update our V2 timestamp...
        }
    }

    Maintenant, j'ai les anciens et les nouveaux messages de la sérialisation/désérialisation correctement, et mon Timestamp comprend maintenant DateTime.Genre! Rien de cassé.

    Toutefois, cela ne signifie pas que les DEUX champs seront dans tous les nouveaux messages à l'avenir. La touche finale consiste à utiliser un temps d'exécution de la sérialisation décision d'exclure le vieux Timestamp (remarque cela ne fonctionnera pas si c'est à l'aide protobuf de l'attribut obligatoire!!!)

        bool ShouldSerialize__Timestamp_v1() 
    {
        return __Timestamp_v1 != DateTime.MinValue;
    }

    Et c'est tout. J'ai une belle unité de test qui fait de bout en bout, si quelqu'un en veut...

    Je sais que ma méthode s'appuie sur l' .NET magie, mais je crois que le concept pourrait être traduite dans d'autres langues....

    InformationsquelleAutor James Joyce