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.

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

feat: Doc fetch from cursor to be non-blocking and blocking #23

Merged
merged 2 commits into from
Nov 11, 2024

Conversation

WanYixian
Copy link
Collaborator

Description

Doc fetch from cursor to be non-blocking and blocking

Related code PR

risingwavelabs/risingwave#18675

Related doc issue

Resolve risingwavelabs/risingwave-docs#2672

Copy link

@hzxa21 hzxa21 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rest LGTM

@@ -83,33 +83,39 @@ If you specify `FULL` instead of the `since_clause`, the subscription cursor sta
FETCH from cursor function is currently only supported in the PSQL simple query mode. If you are using components like JDBC that default to the extended query mode, please manually set the mode to simple query mode.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extended mode is also supported in risingwavelabs/risingwave#17821 starting from v2.0

(1 row)
```

The `op` column in the result stands for the change operations. It has four options: `insert`, `update_insert`, `delete`, and `update_delete`. For a single UPDATE statement, the subscription log will contain two separate rows: one with `update_insert` and another with `update_delete`. This is because RisingWave treats an UPDATE as a delete of the old value followed by an insert of the new value. As for `rw_timestamp`, it corresponds to the Unix timestamp in milliseconds when the data was written.
In the example above, the `op` column in the result indicates the type of change operations. There are four options: `insert`, `update_insert`, `delete`, and `update_delete`. For a single UPDATE statement, the subscription log will contain two separate rows: one with `update_insert` and another with `update_delete`. This is because RisingWave treats an UPDATE as a delete of the old value followed by an insert of the new value. As for `rw_timestamp`, it corresponds to the Unix timestamp in milliseconds when the data was written.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The four options are in camelCase instead of snake_case: Insert, Delete, UpdateInsert, UpdateDelete.


Note that each time `FETCH NEXT FROM cursor_name` is called, it will return one row of incremental data from the subscribed table. It does not return all the incremental data at once, but requires the user to repeatedly call this statement to fetch the data.
```sql
FETCH NEXT/n FROM cursor_name WITH (timeout = 'xx');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's give a concrete example for timeout: replace timeout = 'xx' to timeout = '1s'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document: feat(subscription): support blocking cursor
2 participants