Protobuf-net enum zgodność wsteczna

Question

Próbowałem dodać nową wartość wyliczeniową dla pewnej klasy z serią protobuf w nowej wersji aplikacji, a podczas testowania zauważyłem, że poprzednia wersja wygeneruje wyjątek, biorąc pod uwagę ten nowy format pliku :

 
An unhandled exception of type 'ProtoBuf.ProtoException' occurred in protobuf-net.dll 
Additional information: No {enum-type-name} enum is mapped to the wire-value 3 

jest dość oczywiste, że to mówi mi, że nie ma wartości wyliczenia dla wartości int z 3, ale zawsze miałem pojęcia, że ​​Protocol Buffers defaulted to the zero-valued ("default") enum value (jeśli taki istnieje), w przypadku gdy rzeczywista wartość enum nie można przypisać do.

celu wyjaśnienia, to może być powielana stosując następujący przykład (jestem celowo robi krok deserializacjia do innej klasy naśladować starą aplikację próby załadowania nowego formatu):

// --- version 1 --- 

public enum EnumV1 
{ 
    Default = 0, 
    One = 1, 
    Two = 2 
} 

[ProtoContract] 
public class ClassV1 
{ 
    [ProtoMember(1)] 
    public EnumV1 Value { get; set; } 
} 



// --- version 2 --- 

public enum EnumV2 
{ 
    Default = 0, 
    One = 1, 
    Two = 2, 
    Three = 3 // <- newly added 
} 

[ProtoContract] 
public class ClassV2 
{ 
    [ProtoMember(1)] 
    public EnumV2 Value { get; set; } 
} 

i następujący kod zawiedzie:

// serialize v2 using the new app 
var v2 = new ClassV2() { Value = EnumV2.Three }; 
var v2data = Serialize(v2); 

// try to deserialize this inside the old app to v1 
var v1roundtrip = Deserialize<ClassV1>(v2data); 

Od V1 jest na otwartej przestrzeni, jest jakiś metadanych można używać podczas szeregowania w v2, aby uniknąć tego problemu? Mogę, oczywiście, wydostać się z tego problemu, przepisując v2, aby użyć oddzielnej właściwości i pozostawić wartości wyliczeniowe niezmodyfikowane, ale chciałbym, aby w miarę możliwości były one zgodne wstecz.

Answer 1

Ponieważ v1 jest na otwartej przestrzeni, jest jakiś metadanych można używać podczas szeregowania w v2, aby uniknąć tego problemu? Mogę, oczywiście, wydostać się z tego problemu, przepisując v2, aby użyć oddzielnej właściwości i pozostawić wartości wyliczeniowe niezmodyfikowane, ale chciałbym, aby w miarę możliwości były one zgodne wstecz.

czego doświadczamy jest protobuf netto bug opisany tutaj protobuf-net - issue #422: Invalid behaviour while deserializing unknown enum value.

Wygląda na to, że nie jest jeszcze poprawiony, zgodnie z tym protobuf-net faulty enum exception (issue 422) need a good workaround (i oczywiście Twój post).

Niestety, musisz albo naprawić kod źródłowy protobuf-net lub użyć obejścia, o którym mowa.

UPDATE: Sprawdziłem kodu w repozytorium GitHub i upewnieniu się, że problem nie jest jeszcze ustalona. Oto problematyczny kod wewnątrz EnumSerializer.cs (komentarzu ISSUE #422 jest moje):

public object Read(object value, ProtoReader source) 
{ 
    Helpers.DebugAssert(value == null); // since replaces 
    int wireValue = source.ReadInt32(); 
    if(map == null) { 
     return WireToEnum(wireValue); 
    } 
    for(int i = 0 ; i < map.Length ; i++) { 
     if(map[i].WireValue == wireValue) { 
      return map[i].TypedValue; 
     } 
    } 
    // ISSUE #422 
    source.ThrowEnumException(ExpectedType, wireValue); 
    return null; // to make compiler happy 
} 

Answer 2

Twój ClassV1 nie ma kompatybilności do przodu.

Wdrożyłbym umowę Proto w taki sposób, że serializuje/deserializuje łańcuch reprezentujący wartość wyliczeniową. W ten sposób możesz samodzielnie zarządzać awarią do wartości domyślnej. Właściwość Value nie byłaby serializowana/deserializowana.

public enum EnumV1 
{ 
    Default = 0, 
    One = 1, 
    Two = 2 
} 

public enum EnumV2 
{ 
    Default = 0, 
    One = 1, 
    Two = 2, 
    Three = 3 // <- newly added 
} 

[ProtoContract] 
public class ClassV1 
{ 
    [ProtoMember(1)] 
    public string ValueAsString 
    { 
     get { return Value.ToString(); } 
     set 
     { 
      try 
      { 
       Value = (EnumV1) Enum.Parse(typeof (EnumV1), value); 
      } 
      catch (Exception) 
      { 
       Value = EnumV1.Default; 
      } 
     } 
    } 

    public EnumV1 Value { get; set; } 
} 

[ProtoContract] 
public class ClassV2 
{ 
    [ProtoMember(1)] 
    public string ValueAsString 
    { 
     get { return Value.ToString(); } 
     set 
     { 
      try 
      { 
       Value = (EnumV2)Enum.Parse(typeof(EnumV2), value); 
      } 
      catch (Exception) 
      { 
       Value = EnumV2.Default; 
      } 
     } 
    } 

    public EnumV2 Value { get; set; } 
} 

Nadal nie rozwiązuje to problemu posiadania klasy produkcyjnej, która nie może być dalej rozwijana.

Answer 3

Możesz dodać atrybut DefaultValue do właściwości prong proto.

[ProtoContract] 
public class ClassV1 
{ 
    [ProtoMember(1), DefaultValue(EnumV1.Default)] 
    public EnumV1 Value { get; set; } 
} 

Aby wyjaśnić, w jaki sposób należy zainicjować właściwość dla domyślnego przypadku.

Answer 4

Dodanie [ProtoContract(EnumPassthru=true)] do twoich wyliczeń pozwoli protobuf-net na deserializację nieznanych wartości.

Niestety, nie ma sposobu, aby z mocą wsteczną naprawić swój v1. Będziesz musiał użyć innej właściwości.