feat: support update for memory catalog#1002
Conversation
35ac16d to
3c14f04
Compare
jonathanc-n
left a comment
There was a problem hiding this comment.
Add TODO for support for atomic swap to new metadata file. We can look to implement for other catalogs after merge.
| } | ||
| } | ||
|
|
||
| fn new_metadata_location(&self, location: &str) -> String { |
There was a problem hiding this comment.
This should include version increment, and be in the format as defined in the spec.
liurenjie1024
left a comment
There was a problem hiding this comment.
Thanks @ZENOTME for this pr. The reason we don't add update table support before is that currently the table transaction api is not complete yet, and we should not add this in catalog in such a way.
Hi @liurenjie1024, I'm confused why we don't add update table support before transaction api is not complete yet. Which transaction API should we support first?🤔 According to my understanding, the update table implementation of the catalog is decoupled with the transaction API. I notice that for the other catalog, except RestCatalog. Their update behaviour based on the MetastoreCatalog. MetastoreCatalog will provide a unified way to write metadata file. Is your mean is that we should complete MetasoreCatalog first? |
|
This pull request has been marked as stale due to 30 days of inactivity. It will be closed in 1 week if no further activity occurs. If you think that’s incorrect or this pull request requires a review, please simply write any comment. If closed, you can revive the PR at any time and @mention a reviewer or discuss it on the dev@iceberg.apache.org list. Thank you for your contributions. |
|
This pull request has been closed due to lack of activity. This is not a judgement on the merit of the PR in any way. It is just a way of keeping the PR queue manageable. If you think that is incorrect, or the pull request requires review, you can revive the PR at any time. |
To add runnable update example #999, we should support update forthe memory catalog first.