Page History

...

By extending the same sort of structure, we can encode almost any value with a type that is supported, including adding support for more complex types like dates or UUIDs. Clients can write their own encoders and driver developers can This should make it possible to write serializers and should enable driver developers to write auto-serializers that will serialize these objects via reflection to Protobuf in a manner similar to how JSON is currently serialized:.

message Struct {
  string typeName = 1;
  repeated StructEntry entries = 2;

}
message StructEntry {
  string fieldName = 1;
  oneof value {
    int32Struct intFieldnestedStruct = 2;
    int64 int64 longFieldnumericValue = 3;
    int32byte shortFieldbyteValue = 4;
    bytebool byteFieldbooleanValue = 5;
    booldouble booleanFielddoubleValue = 6;
    doublefloat doubleFieldfloatValue = 7;
    floatbytes floatFieldbinaryValue = 8;
    bytesstring binaryFieldstringValue = 9;
    string stringField = 10;
    google.protobuf.NullValue nullFieldnullValue = 1110;
  }
}

The typeName field can be used for other clients to recognize the same type. Internally, it will be stored in the PDXInstance that this is converted to, but that detail shouldn't need to be exposed to the userdriver developer.

So for example, given the following class and value:

...

Ideally, a driver developer would provide annotations or registration for client application developers to register their types. In languages that use setters and getters by convention, it would probably be more idiomatic to refer to setters getters for reflection rather than the member variables of the object.

...

Type registration will be per-connection (meaning IDs cannot be cached between connections). This eliminates the need to keep synchronization on the server, as well as decoupling client type registrations from the internal details of PDX. It also means that the clients drivers only have to keep track of a relatively small amount of data.

It will be safe for a client driver to register the same type multiple times on a single connection, and it should get back the same ID every time.

...

GetRequest{
  key: EncodedValue{intValue: 42111},
  value: EncodedValue{
    structValue: Value{
      id: 42,
      fields: [
        ValueField{stringField: "Amy"},
        ValueField{intField: 4244}
      ]
    }
  }
}

Message Definitions 

Anchor
message-definitions message-definitions

...

A driver developer may wish to provide a way for users to register types before sending values.

Client Driver developers will have to make sure that types they want to use in different language clients can be correlated. So package names may or may not make sense.