demo_service.proto

syntax = "proto3";

package example;
import "google/protobuf/empty.proto";
import "github.com/infobloxopen/protoc-gen-gorm/options/gorm.proto";
import "google/protobuf/field_mask.proto";
import "github.com/infobloxopen/atlas-app-toolkit/query/collection_operators.proto";

option go_package = "github.com/infobloxopen/protoc-gen-gorm/example/feature_demo;example";

// IntPoint is a basic message type representing a single cartesian point
// that we want to store in a database
message IntPoint {
  option (gorm.opts).ormable = true;
  uint32 id = 1;
  int32 x = 2;
  int32 y = 3;
}

// Convention dictates that we have separate Request and Response message types
// for each API call, so that they can be alterred later without having to fear
// breaking a contract in any of the other services.

message CreateIntPointRequest {
    // Convention dictates that this field be of the given type, and be
    // named 'payload' in order to autogenerate the handler
    IntPoint payload = 1;
}

message CreateIntPointResponse {
    // Convention also requires that the return type be the same and named 'result'
    IntPoint result = 1;
}

message ReadIntPointRequest {
    // For a read request, the id field is the only to be specified
    uint32 id = 1;
    infoblox.api.FieldSelection fields = 2;
}

message ReadIntPointResponse {
    // Again the type with 'result' name
    IntPoint result = 1;
}

message UpdateIntPointRequest {
    IntPoint payload = 1;
    google.protobuf.FieldMask gerogeri_gegege = 2;
}

message UpdateIntPointResponse {
    IntPoint result = 1;
}

message DeleteIntPointRequest {
    // Only the id is needed for a delete request
    uint32 id = 1;
}

message DeleteIntPointsRequest {
    // Only the id is needed for a delete request
    repeated uint32 ids = 1;
}

// By convention, on DELETE no response data is given, so either a
// google.protobuf.empty, or an empty struct is sufficient
message DeleteIntPointResponse {
}

message ListIntPointResponse {
    // Note repeated field and plural name 'results'
    repeated IntPoint results = 1;
    infoblox.api.PageInfo page_info = 2;
}

message ListSomethingResponse {
    // Note repeated field and plural name 'results'
    repeated Something results = 1;
    infoblox.api.PageInfo page_info = 2;
}


// A dummy type to demo an rpc that can't be autogenerated
message Something {
    option (gorm.opts).ormable = true;
    string field = 1;
}

message ListIntPointRequest {
    infoblox.api.Filtering filter = 1;
    infoblox.api.Sorting order_by = 2;
    infoblox.api.FieldSelection fields = 3;
    infoblox.api.Pagination paging = 4;
}

service IntPointService {
  // This option tells protoc-gen-gorm to generate the calls and stubs
  option (gorm.server).autogen = true;
  // The convention requires the rpc names have Create/Read/Update/List/Delete
  // as a prefix. The type is inferred from the response (except for delete),
  // so multiple objects can have CURDL handlers in the same service, provided
  // they are given unique suffixes
  rpc Create ( CreateIntPointRequest ) returns ( CreateIntPointResponse ) {}
  rpc Read ( ReadIntPointRequest ) returns ( ReadIntPointResponse ) {}
  rpc Update ( UpdateIntPointRequest ) returns ( UpdateIntPointResponse ) {}
  rpc List ( ListIntPointRequest ) returns ( ListIntPointResponse ) {}
  rpc ListSomething( google.protobuf.Empty ) returns ( ListSomethingResponse ) {}
  rpc Delete ( DeleteIntPointRequest ) returns  ( DeleteIntPointResponse ) {
      // This option is required because the type/table can't be inferred
      // by the return type
      option (gorm.method).object_type = "IntPoint";
  }
  // CustomMethod can't be autogenerated as it matches no conventions, it will
  // become a stub
  rpc CustomMethod ( google.protobuf.Empty ) returns  ( google.protobuf.Empty ) {}
  // CreateSomething also doesn't match conventions and will become a stub
  rpc CreateSomething ( Something ) returns  ( Something ) {}
}

service IntPointTxn {
  // This option tells protoc-gen-gorm to generate the calls and stubs, and
  // the transaction middleware will be used
  option (gorm.server) = {autogen: true, txn_middleware: true};
  // The convention requires the rpc names have Create/Read/Update/List/Delete
  // as a prefix. The type is inferred from the response (except for delete),
  // so multiple objects can have CURDL handlers in the same service, provided
  // they are given unique suffixes
  rpc Create ( CreateIntPointRequest ) returns ( CreateIntPointResponse ) {}
  rpc Read ( ReadIntPointRequest ) returns ( ReadIntPointResponse ) {}
  rpc Update ( UpdateIntPointRequest ) returns ( UpdateIntPointResponse ) {}
  rpc List ( ListIntPointRequest ) returns ( ListIntPointResponse ) {}
  rpc Delete ( DeleteIntPointRequest ) returns  ( DeleteIntPointResponse ) {
      // This option is required because the type/table can't be inferred
      // by the return type
      option (gorm.method).object_type = "int_point";
  }
  rpc DeleteSet ( DeleteIntPointsRequest ) returns  ( DeleteIntPointResponse ) {
      // This option is required because the type/table can't be inferred
      // by the return type
      option (gorm.method).object_type = "int_point";
  }
  // CustomMethod can't be autogenerated as it matches no conventions, it will
  // become a stub
  rpc CustomMethod ( google.protobuf.Empty ) returns  ( google.protobuf.Empty ) {}
  // CreateSomething also doesn't match conventions and will become a stub
  rpc CreateSomething ( Something ) returns  ( Something ) {}
}

message Circle {
    option (gorm.opts).ormable = true;
    uint32 r = 1;
}

message ListCircleRequest {
}

message ListCircleResponse {
    repeated Circle results = 1;
}

service CircleService {
    option (gorm.server).autogen = true;
    rpc List ( ListCircleRequest ) returns ( ListCircleResponse ) {}
}