Service Expected message type

[omid pourhadi]

Hi,

I'm new to protobuf and I'm trying to create a simple CRUD app with grpc my proto file is :

service AcceptorService {  

  rpc create (Acceptor) returns (Acceptor) {};

  rpc update (Acceptor) returns (Acceptor) {};

  rpc list(Pagination) returns (AcceptorList) {};  

  rpc count(Pagination) returns (AcceptorCount) {};  

}

message Acceptor {

  string name = 1;

  string acceptorCode = 3;

}

message AcceptorList {

    repeated Acceptor acceptors=100;    

}

message AcceptorCount {

    int64 count = 1;

}

message Pagination{

int32 page = 1;

int32 pageSize = 2;

}

What I want to achieve is not to use message as return type for example I want to change count rpc as follow : 

service AcceptorService {   

  rpc count(int32 page, int32 pageSize) returns (int32 count) {};  

}

is it possible ? because I get this error proto:15:34: Expected message type.

PS: I'm using proto3

[omid pourhadi]

and sometimes I don't want to pass any message type to rpc method 

rpc count() returns (int32 count) {};  

[Adam Cozzette]

A message type is required for both the request and response. You can always use google.protobuf.Empty (from src/google/protobuf/empty.proto) as a placeholder empty message.

On Tue, Sep 25, 2018 at 6:23 AM omid pourhadi <omidpo...@gmail.com> wrote:

and sometimes I don't want to pass any message type to rpc method 

rpc count() returns (int32 count) {};  

--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to protobuf+u...@googlegroups.com.
To post to this group, send email to prot...@googlegroups.com.
Visit this group at https://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/d/optout.

[Ananya Bhat]

Hi,

I am new to protobuf. 

I have question related to similar usecase.

Please clarify my doubts to decide better message specification

I have definition something like below

Option A

message Student

{

message Empty

{

}

//Name of the Student

optional string name = 1;

// Year of Passing

optional string YOP  = 2;

message Certificate

{

// Certificate name

optional string name    = 1;

// Absolute location of the file on the disk

// e.g. C:\university\2019\

optional string path    = 2;

//strudent Identification code

optional string ID      = 3;

// section e.g. "A", "B"

optional string section = 4;

// Certificate type

optional string type = 5;

}

optional Certificate cert = 3;

}

service StudentService

{

rpc getStudentName(Strudent.Empty) returns (Student);

rpc getCertificate(Student.Certificate) returns (Student.Certificate);

}

alternatively

Option B

message Student

{

//Name of the Student

optional string name = 1;

message FilePath

{

optional string path = 1;

}

message Certificate

{

optional string   name = 1;

optional Filepath path = 2;

//strudent Identification code

optional string ID      = 3;

// section e.g. "A", "B"

optional string section = 4;

// Certificate type

optional string type = 5;

}

optional Certificate cert = 2;

}

service StudentService

{

rpc getStudentName(Strudent.Empty) returns (Student);

rpc getCertificate(Student.Certificate.FilePath) returns (Student.Certificate);

}

In Option A, file path can not be specified to get the certificate. Full message needs to be passed.

In Option B, there is a extra type introduced to simplify

However it adds nested definition for path 

as it has to be cert.path.path for getters and setters 

Please clarify the following

Why scalar types can not be used as IN parameter or OUT parameters of Service RPCs?

How partial messages can be explicitly specified in service RPCs without using nesting?

 

[Adam Cozzette]

On Sat, Jun 29, 2019 at 5:22 AM Ananya Bhat <ananya...@gmail.com> wrote:

Please clarify the following

Why scalar types can not be used as IN parameter or OUT parameters of Service RPCs?

I think it just simplifies everything to use message types only. If we allowed non-message types as requests or responses then it would also be difficult to change the API over time, whereas with messages it's easy to add new fields.

 

How partial messages can be explicitly specified in service RPCs without using nesting?

As far as I know there is no way to specify partial messages in the service schema. However, you can always specify the full message with the understanding that it won't necessarily have a value set in every field.