[PROTOCOL RFC] Catalog-managed Tables#4382
Conversation
scovich
left a comment
There was a problem hiding this comment.
Clear and easy to read, thanks!
The PR description and associated issue don't seem to indicate why this new RFC replaces the original one, tho?
xzhseh
left a comment
There was a problem hiding this comment.
Great RFC, thanks for the excellent work!
+1 on @scovich's comment to have detailed reasons why this RFC replaces the previous one.
| are already durable and visible to readers. For example, a catalog would want to block attempts to | ||
| drop the NOT NULL constraint on a column which is referenced by a FOREIGN KEY constraint in a | ||
| different table. |
There was a problem hiding this comment.
For example, a catalog would want to block attempts to drop the NOT NULL constraint on a column which is referenced by a FOREIGN KEY constraint in a different table.
Is this functionality already implemented in the current Delta codebase? For Catalog-Owned enabled tables, should Catalog Client takes the responsibility to check/block the attempt - or it depends on the actual Catalog implementation?
There was a problem hiding this comment.
You mean in our Delta Catalog? Hm. I'm not sure. I'd think this would instead be the responsibility of, say, a Glue catalog or Unity catalog implementation.
There was a problem hiding this comment.
Is this functionality already implemented in the current Delta codebase? For Catalog-Owned enabled tables, should Catalog Client takes the responsibility to check/block the attempt - or it depends on the actual Catalog implementation?
This sort of functionality belongs to the catalog's own client (Glue, UC, etc) that interacts with Delta. The RFC only cares to ensure that catalogs are able to perform such checks, not whether/how they do it.
…ckfilled commit files (#4399) <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/delta-io/delta/blob/master/CONTRIBUTING.md 2. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...'. 3. Be sure to keep the PR description updated to reflect all changes. 4. Please write your PR title to summarize what this PR proposes. 5. If possible, provide a concise example to reproduce the issue for a faster review. 6. If applicable, include the corresponding issue number in the PR title and link it in the body. --> #### Which Delta project/connector is this regarding? <!-- Please add the component selected below to the beginning of the pull request title For example: [Spark] Title of my pull request --> - [x] Spark - [ ] Standalone - [ ] Flink - [ ] Kernel - [ ] Other (fill in here) ## Description Per [Catalog-Owned RFC](#4382), we decided to use `_delta_log/_staged_commits/` folder to store all staged/unbackfilled commit files, which is different from [Manged Commits RFC](https://github.com/delta-io/delta/blob/master/protocol_rfcs/managed-commits.md)'s `_delta_log/_commits/` folder. This PR changes the `COMMIT_SUBDIR` in both `CoordinatedCommitsUtils.java` and `FilesNames.scala`, plus update all the relevant comments/UTs. <!-- - Describe what this PR changes. - Describe why we need the change. If this PR resolves an issue be sure to include "Resolves #XXX" to correctly link and close the issue upon merge. --> ## How was this patch tested? Through existing UTs. <!-- If tests were added, say they were added here. Please make sure to test the changes thoroughly including negative and positive cases if possible. If the changes were tested in any way other than unit tests, please clarify how you tested step by step (ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future). If the changes were not tested, please explain why. --> ## Does this PR introduce _any_ user-facing changes? No, the change for commit subdirectory should **_not_** be a user-facing change. <!-- If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible. If possible, please also clarify if this is a user-facing change compared to the released Delta Lake versions or within the unreleased branches such as master. If no, write 'No'. -->
<!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/delta-io/delta/blob/master/CONTRIBUTING.md 2. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...'. 3. Be sure to keep the PR description updated to reflect all changes. 4. Please write your PR title to summarize what this PR proposes. 5. If possible, provide a concise example to reproduce the issue for a faster review. 6. If applicable, include the corresponding issue number in the PR title and link it in the body. --> #### Which Delta project/connector is this regarding? <!-- Please add the component selected below to the beginning of the pull request title For example: [Spark] Title of my pull request --> - [X] Spark - [ ] Standalone - [ ] Flink - [ ] Kernel - [ ] Other (fill in here) ## Description <!-- - Describe what this PR changes. - Describe why we need the change. If this PR resolves an issue be sure to include "Resolves #XXX" to correctly link and close the issue upon merge. --> This PR implements the RFC "CatalogOwned" table feature to Delta-IO. #4382 ## How was this patch tested? Existing & New unit tests. More tests will be added. <!-- If tests were added, say they were added here. Please make sure to test the changes thoroughly including negative and positive cases if possible. If the changes were tested in any way other than unit tests, please clarify how you tested step by step (ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future). If the changes were not tested, please explain why. --> ## Does this PR introduce _any_ user-facing changes? No. <!-- If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible. If possible, please also clarify if this is a user-facing change compared to the released Delta Lake versions or within the unreleased branches such as master. If no, write 'No'. -->
…ckfilled commit files (delta-io#4399) <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/delta-io/delta/blob/master/CONTRIBUTING.md 2. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...'. 3. Be sure to keep the PR description updated to reflect all changes. 4. Please write your PR title to summarize what this PR proposes. 5. If possible, provide a concise example to reproduce the issue for a faster review. 6. If applicable, include the corresponding issue number in the PR title and link it in the body. --> #### Which Delta project/connector is this regarding? <!-- Please add the component selected below to the beginning of the pull request title For example: [Spark] Title of my pull request --> - [x] Spark - [ ] Standalone - [ ] Flink - [ ] Kernel - [ ] Other (fill in here) ## Description Per [Catalog-Owned RFC](delta-io#4382), we decided to use `_delta_log/_staged_commits/` folder to store all staged/unbackfilled commit files, which is different from [Manged Commits RFC](https://github.com/delta-io/delta/blob/master/protocol_rfcs/managed-commits.md)'s `_delta_log/_commits/` folder. This PR changes the `COMMIT_SUBDIR` in both `CoordinatedCommitsUtils.java` and `FilesNames.scala`, plus update all the relevant comments/UTs. <!-- - Describe what this PR changes. - Describe why we need the change. If this PR resolves an issue be sure to include "Resolves #XXX" to correctly link and close the issue upon merge. --> ## How was this patch tested? Through existing UTs. <!-- If tests were added, say they were added here. Please make sure to test the changes thoroughly including negative and positive cases if possible. If the changes were tested in any way other than unit tests, please clarify how you tested step by step (ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future). If the changes were not tested, please explain why. --> ## Does this PR introduce _any_ user-facing changes? No, the change for commit subdirectory should **_not_** be a user-facing change. <!-- If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible. If possible, please also clarify if this is a user-facing change compared to the released Delta Lake versions or within the unreleased branches such as master. If no, write 'No'. -->
<!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, please read our contributor guidelines: https://github.com/delta-io/delta/blob/master/CONTRIBUTING.md 2. If the PR is unfinished, add '[WIP]' in your PR title, e.g., '[WIP] Your PR title ...'. 3. Be sure to keep the PR description updated to reflect all changes. 4. Please write your PR title to summarize what this PR proposes. 5. If possible, provide a concise example to reproduce the issue for a faster review. 6. If applicable, include the corresponding issue number in the PR title and link it in the body. --> #### Which Delta project/connector is this regarding? <!-- Please add the component selected below to the beginning of the pull request title For example: [Spark] Title of my pull request --> - [X] Spark - [ ] Standalone - [ ] Flink - [ ] Kernel - [ ] Other (fill in here) ## Description <!-- - Describe what this PR changes. - Describe why we need the change. If this PR resolves an issue be sure to include "Resolves #XXX" to correctly link and close the issue upon merge. --> This PR implements the RFC "CatalogOwned" table feature to Delta-IO. delta-io#4382 ## How was this patch tested? Existing & New unit tests. More tests will be added. <!-- If tests were added, say they were added here. Please make sure to test the changes thoroughly including negative and positive cases if possible. If the changes were tested in any way other than unit tests, please clarify how you tested step by step (ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future). If the changes were not tested, please explain why. --> ## Does this PR introduce _any_ user-facing changes? No. <!-- If yes, please clarify the previous behavior and the change this PR proposes - provide the console output, description and/or an example to show the behavior difference if possible. If possible, please also clarify if this is a user-facing change compared to the released Delta Lake versions or within the unreleased branches such as master. If no, write 'No'. -->
|
Thanks for the great work here! One minor naming suggestion: would the term “Managed” may better reflect the catalog’s role in governing both metadata and data operations like commits and reads. It also aligns with common terminology in systems like Snowflake-managed Iceberg tables [1] and Unity Catalog managed tables [2], where “managed” indicates that the catalog is responsible for the lifecycle of the table. |
|
@michelleon -- That's a great suggestion. Will implement that. Thanks! |
scovich
left a comment
There was a problem hiding this comment.
LGTM, but please address grammar nits before merging.
xzhseh
left a comment
There was a problem hiding this comment.
LGTM w/ two clarification questions!
bfa3866 to
69b138b
Compare
This PR
catalogManagedtable feature protocol RFC for issue [PROTOCOL RFC] Catalog-managed Tables #4381For details about why we are proposing this RFC and why we are rejecting the Coordinated Commits RFC, please see the tracking issue #4381
Design doc: Design Doc: Catalog-Managed Delta Table Feature