AntidoteDB / AntidoteDB/antidote
Update protocol buffers interface to conform to the protocol buffers specification
- Vorherrschende Sprache
- Erlang
- Sterne
- 892
- Forks
- 92
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beschreibung
The current protocol buffers interface of Antidote has some strange constructs that, if interpreted using the protocol buffer specification, are not handled correctly by Antidote.
From the protocol buffers spec (https://developers.google.com/protocol-buffers/docs/proto):
> As mentioned above, elements in a message description can be labeled optional. A well-formed message may or may not contain an optional element. When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object is set to the default value for that field.
and further:
> If the default value is not specified for an optional element, a type-specific default value is used instead: for strings, the default value is the empty string. For bools, the default value is false. For numeric types, the default value is zero. For enums, the default value is the first value listed in the enum's type definition.
There are, for example, some messages in the interface, that are not interpreted like this:
- `ApbStartTransaction` includes a `timestamp` field of type bytes. The default value for this type is the empty byte-sequence. But Antidote chokes on an empty byte-sequence because it tries to decode it as a vector-clock.
- `ApbIntegerUpdate` includes two fields `inc` and `set`. According to the specification, a message including an integer update where the `set` field is set to 0 would be decoded to a message where both `inc` and `set` are set to 0. How should such a message be interpreted?
Additionally, there are messages that could better be defined using the `oneof` construct such as `ApbUpdateOp` and `ApbReadObjectsResp`.
There is also one message, which is reused from the riak interface: `RpbErrorResp`. This should instead be an independent message of the Antidote interface to be self-contained.
When reworking the protocol buffers interface, it should be considered moving from `riak_pb` to a custom implementation. riak_pb introduces unnecessary complexity and an additional dependency to `riak_api` because of the use of `riak_api_pb_service`. Instead, the implementation of the protocol buffers interface can be done using `gpb` (https://github.com/tomas-abrahamsson/gpb) which also supports the latest version `proto3`.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Bewertung
Dieses Issue wurde noch nicht bewertet.