feat: support update for memory catalog #1002
Conversation
ZENOTME
force-pushed
the
memory_catalog_update
branch
from
35ac16d to
3c14f04
Compare
| @@ -53,6 +53,30 @@ impl MemoryCatalog { | |||
| warehouse_location, | |||
| } | |||
| } | |||
|
|
|||
| 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.
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? |
To add runnable update example #999, we should support update forthe memory catalog first.