cockroachdb / cockroachdb/cockroach

cdc: UX consistency for changefeeds, like other database objects

Open
#93,459 2 comments 2 reactions 0 assignees View on GitHub
A-cdc C-enhancement E-quick-win E-starter T-cdc
Dominant language
Go
Stars
32.5k
Forks
4.1k
PR merge metrics
PR metrics pending

Description

Changefeeds are “just” jobs, they are not an entity on the order of tables or indexes. While there is deeper work we could do for changefeeds to have descriptors, etc, we can add some UX in the short term to give changefeeds syntactic consistency with tables, indexes, etc. To be clear, changefeeds remain jobs, this is all UX.

- `CREATE CHANGEFEED opt_name FOR TABLE`...
`opt_name` is new. Presumably stored in the job protobuf. We might follow the [naming logic for indexes](https://www.cockroachlabs.com/docs/stable/create-index.html#parameters), where the name is optional and gets auto-created if not specified. If so, need a migration.
- `ALTER CHANGEFEED RENAME TO `
Hmm, this already uses Job ID.
- `SHOW CHANGEFEEDS`
An alias to `SHOW CHANGEFEED JOBS`, new column for name. Hide Job ID?
- `DROP CHANGEFEED `
Calls [`CANCEL JOB`](https://www.cockroachlabs.com/docs/stable/create-and-configure-changefeeds.html#cancel). Returns error if the specified name is not a changefeed job.
- `DROP ALL CHANGEFEEDS`
Alias for `CANCEL ALL CHANGEFEED JOBS`
- `PAUSE CHANGEFEED `
Calls [`PAUSE JOB`](https://www.cockroachlabs.com/docs/stable/create-and-configure-changefeeds.html#pause). Returns error if the specified name is not a changefeed job.
- `PAUSE ALL CHANGEFEEDS`
Alias for `PAUSE ALL CHANGEFEED JOBS`
- `RESUME CHANGEFEED `
Calls [`RESUME JOB`](https://www.cockroachlabs.com/docs/stable/create-and-configure-changefeeds.html#resume). Returns error if the specified name is not a changefeed job.
- `RESUME ALL CHANGEFEEDS`
Alias for `RESUME ALL CHANGEFEED JOBS`
- `SHOW CREATE CHANGEFEED `
See also https://github.com/cockroachdb/cockroach/issues/69348

Proposed: for clarity, these new commands should only accept a name and not a job_id. If you want to operate with job_id's, use the existing syntax (which we will not deprecate). Alternatively, can we handle either a name or job_id without ambiguity or surprises? Or, should we not bother with their naming part and just use the following sugar with job_id?

We’d want to take care to do this in a way that we won’t regret in the future, by painting ourselves into a syntactic or semantic corner. Likely low-risk.

Jira issue: CRDB-22346

Epic CRDB-25041

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.