CODEWITHSUNDEEP
c#.netprotocol-buffersprotobuf-net
Anthony
Anthony

Reputation: 2289

protobuf-net Inheritance & Field Numbers

I am trying to construct a serialisation system for our application that must be able to handle inheritance. To further complicate matters the application is extensible so types might are very unlikely to be known at compile time.

I have read through a previous stackoverflow question that was answered and that helped me get a long way to my goal but I have hit a stumbling block that is probably more of a lack of understanding than any real issue!

So this is the code that I have currently...

public interface IBaseFrame
{

}

public class BasicDataFrame : IBaseFrame
{

}

public class AnotherFrame : BasicDataFrame
{

}

. . . .

RuntimeTypeModel model = TypeModel.Create();
MetaType baseType = model.Add(typeof(IBaseFrame), true);
MetaType basicFrameType = model.Add(typeof(BasicDataFrame),true);

baseType.AddSubType(7, typeof(BasicDataFrame));
model.Add(typeof(AnotherFrame), true);

basicFrameType.AddSubType(8, typeof(AnotherFrame));

Now this code works correctly (as far as I can tell!) and all is good in the world... My concern is where the values 7 and 8 are used in the code above for the fieldNumber argument of the AddSubType method.

As the plugins are enumerated I am registering their frame types with the SerialisationManager and I add them to the model with an incrementing counter for the fieldNumber (I start it at an arbitrarily large number so I don't have to worry about extending the base classes in the future).

I am worried that if the plugins are enumerated in a different order or new ones are added (or removed) then the auto generated fieldNumber is going to be different for the different sub types that will then cause issues with sharing log files between users (who may have different plugins and therefore subtypes) or even files on the same system when a plugin may have been removed.

Is there any cunning way of dealing with this kind of inheritance automatically and without introducing compatibility issues in the future or when plugins change or do I need to come up with a mechanism where these fieldNumbers can be guaranteed to remain contant across all installations?

Any help or advice that can be given would be greatly appreciated!

Upvotes: 1

Views: 1368

Answers (1)

Marc Gravell
Marc Gravell

Reputation: 1062780

No magic here; the numbers are essentially part of the contract, and it is important that they can be reliably reproduced if you want to deserialize data you stored previously. If the data can't be known at compile-time, maybe configuration or some external registry of types to field numbers may help. Your concerns are accurate.

Upvotes: 2

Related Questions