Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[DocDB] Trivial service methods #11205

Closed
spolitov opened this issue Jan 25, 2022 · 0 comments
Closed

[DocDB] Trivial service methods #11205

spolitov opened this issue Jan 25, 2022 · 0 comments
Assignees
@spolitov
Labels
area/docdb YugabyteDB core features

Comments

@spolitov
Copy link
Contributor

Description

Currently, most of our RPC endpoints has a trivial implementation, which takes request, synchronously process, and sends the response.
But our generated service methods allow asynchronous processing, which complicates the writing of every method, even it doesn't require asynchronous processing.
This diff adds the ability to specify that method is trivial.
So his service virtual method will have signature:
Result<ResponsePB> Method(const RequestPB& req, CoarseTimePoint deadline);
instead of
void Method(const RequestPB req, ResponsePB* resp, RpcContext context);
@spolitov spolitov added the area/docdb YugabyteDB core features label Jan 25, 2022
@spolitov spolitov self-assigned this Jan 25, 2022
spolitov added a commit that referenced this issue Jan 26, 2022
@spolitov
[#11205] Trivial RPC methods
9ac94af 
Summary:
Currently, most of our RPC endpoints has a trivial implementation, which takes request, synchronously process, and sends the response.
But our generated service methods allow asynchronous processing, which complicates the writing of every method, even it doesn't require asynchronous processing.
This diff adds the ability to specify that method is trivial.
So his service virtual method will have signature:
```Result<ResponsePB> Method(const RequestPB& req, CoarseTimePoint deadline);```
instead of
```void Method(const RequestPB req, ResponsePB* resp, RpcContext context);```

Test Plan: ybd --gtest_filter RpcStubTest.Trivial

Reviewers: dmitry

Reviewed By: dmitry

Subscribers: ybase, bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D14990
@bmatican bmatican mentioned this issue Mar 3, 2022
Closed
@bmatican bmatican closed this as completed Mar 3, 2022
suranjan added a commit that referenced this issue Mar 28, 2022
@suranjan
[BACKPORT 2.12] [CDCSDK] [#9019] CDC SDK API changes
1b50b15 
Summary:
Original commits:
- b04b58a / D14605
- 9ac94af / D14990
Added following CDC admin APIs. The CDC stream is created at the namespace level. It creates the stream on all the tables present at that point in time.
This Stream ID can be used by the CDC client to get the data of the tables. Currently, any table created in this namespace after this command is executed, will not have the stream created for it automatically. The user will need to alter this stream to add/remove the table id.

**Case 1: No tables are present in the database**
```
$ ./yb-admin create_change_data_stream demo
CDC Stream ID: 3ea999960f5f4fe49d5526079cd0eec4

$ ./yb-admin list_change_data_streams
CDC Streams:
streams {
  stream_id: "3ea999960f5f4fe49d5526079cd0eec4"
  options {
    key: "id_type"
    value: "NAMESPACEID"
  }
  options {
    key: "checkpoint_type"
    value: "EXPLICIT"
  }
  options {
    key: "source_type"
    value: "CDCSDK"
  }
  options {
    key: "record_format"
    value: "PROTO"
  }
  options {
    key: "record_type"
    value: "CHANGE"
  }
  options {
    key: "state"
    value: "ACTIVE"
  }
}

$ ./yb-admin get_change_data_stream_info 3ea999960f5f4fe49d5526079cd0eec4
CDC DB Stream Info:
namespace_id: "000033e1000030008000000000000000"

$ ./yb-admin delete_change_data_stream 3ea999960f5f4fe49d5526079cd0eec4
Successfully deleted Change Data Stream ID: 3ea999960f5f4fe49d5526079cd0eec4
```

**Case 2: Some tables are present in the DB**
In this case, we will be getting the table IDs of the respective tables in the relevant responses
```
$ ./yb-admin create_change_data_stream demo
CDC Stream ID: a6e987dbc2af4516b02ab53dfd01cf56

$ ./yb-admin list_change_data_streams
CDC Streams:
streams {
  stream_id: "a6e987dbc2af4516b02ab53dfd01cf56"
  table_id: "000033e1000030008000000000004000"
  table_id: "000033e1000030008000000000004005"
  options {
    key: "id_type"
    value: "NAMESPACEID"
  }
  options {
    key: "checkpoint_type"
    value: "EXPLICIT"
  }
  options {
    key: "source_type"
    value: "CDCSDK"
  }
  options {
    key: "record_format"
    value: "PROTO"
  }
  options {
    key: "record_type"
    value: "CHANGE"
  }
  options {
    key: "state"
    value: "ACTIVE"
  }
}

$ ./yb-admin get_change_data_stream_info a6e987dbc2af4516b02ab53dfd01cf56
CDC DB Stream Info:
table_info {
  stream_id: "a6e987dbc2af4516b02ab53dfd01cf56"
  table_id: "000033e1000030008000000000004000"
}
table_info {
  stream_id: "a6e987dbc2af4516b02ab53dfd01cf56"
  table_id: "000033e1000030008000000000004005"
}
namespace_id: "000033e1000030008000000000000000"

$ ./yb-admin delete_change_data_stream a6e987dbc2af4516b02ab53dfd01cf56
Successfully deleted Change Data Stream ID: a6e987dbc2af4516b02ab53dfd01cf56
```

[#11205] Trivial RPC methods

Currently, most of our RPC endpoints has a trivial implementation, which takes request, synchronously process, and sends the response.
But our generated service methods allow asynchronous processing, which complicates the writing of every method, even it doesn't require asynchronous processing.
This diff adds the ability to specify that method is trivial.
So his service virtual method will have signature:
```Result<ResponsePB> Method(const RequestPB& req, CoarseTimePoint deadline);```
instead of
```void Method(const RequestPB req, ResponsePB* resp, RpcContext context);```

Using std instead of boost lib for declval

Test Plan:
Jenkins: skip
Added unit tests. Have tested it manually.

ybd --gtest_filter RpcStubTest.Trivial

Reviewers: rahuldesirazu, nicolas, vkushwaha, dmitry, sergei

Reviewed By: sergei

Subscribers: bogdan

Differential Revision: https://phabricator.dev.yugabyte.com/D16228
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@spolitov spolitov

Labels
area/docdb YugabyteDB core features
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bmatican @spolitov