AntidoteDB / AntidoteDB/antidote

Update protocol buffers interface to conform to the protocol buffers specification

Offen
#289 0 Kommentare 0 Reaktionen 1 zugewiesene Person Beansprucht von @peterzeller Auf GitHub ansehen
bug
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.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.