I have added example types for pagination in queries and results.
The problem persists that some protobuf types do not contain their identifier (for example Groups, Votes). We can wither work around this by using a wrapper type like Model in this draft or we add the IDs to the types when needed. As there are no actions on Votes me may not need an ID there.
As a workflow example of a client that we should support:
give me all proposals (that can be executed)
execute proposal (with id=xx)
Without an ID in the query result from step 1 the second step would be impossible...
Another inconsistency is the type mismatch in queries and messages:
a create group Message would return the raw key but that can not be used for queries without decoding to uint64: GroupID
Prefix and Range queries feel a bit out of place with this RPC definition. They are quite powerful for receiving/ restoring state for a client but it is ok to hide them in the backend only. We can add more RPC functions instead to cover the cases.
I have added example types for pagination in queries and results. The problem persists that some protobuf types do not contain their identifier (for example Groups, Votes). We can wither work around this by using a wrapper type like
Modelin this draft or we add the IDs to the types when needed. As there are no actions on Votes me may not need an ID there. As a workflow example of a client that we should support:Without an ID in the query result from step 1 the second step would be impossible...
Another inconsistency is the type mismatch in queries and messages:
Prefix and Range queries feel a bit out of place with this RPC definition. They are quite powerful for receiving/ restoring state for a client but it is ok to hide them in the backend only. We can add more RPC functions instead to cover the cases.