amogh-jahagirdar edited a comment on pull request #4071:
URL: https://github.com/apache/iceberg/pull/4071#issuecomment-1039743636
I'm pretty aligned with using ManageSnapshots for the create/replace/remove
branch/tag, renameBranch.
```
public interface ManageSnapshots extends PendingUpdate<Snapshot> {
ManageSnapshots setCurrentSnapshot(long snapshotId);
ManageSnapshots rollbackToTime(long timestampMillis);
ManageSnapshots rollbackTo(long snapshotId);
ManageSnapshots cherrypick(long snapshotId);
ManageSnapshots createBranch(String branch, long snapshotId);
ManageSnapshots renameBranch(String branch, String newBranch);
ManageSnapshots replaceBranch(String branch, long snapshotId);
ManageSnapshots removeBranch(String branchName);
ManageSnapshots createTag(String tag, long snapshotId);
ManageSnapshots replaceTag(String tag, long snapshotId);
ManageSnapshots removeTag(String branchName, String branchName);
ManageSnapshots rollbackTo(String branchName, long snapshotId)
}
```
For cherryPickAll, still not fully fleshed out. I am thinking we have some
kind of notion of a TransactionContext which we can embed in the API
implementation which would allow us to hide transaction details for an API. I
still have not thought through what's a good way to abstract the
passing/setting of a transaction context, but basically I'm thinking of having
a context which can be used internally in API implementations, such that when
API commits , part of the commit is committing this transaction which is self
contained in an API (allowing APIs to perform both metadata and snapshot
updates). Still pretty vague I know :) , but there could be a mechanism to
allow us to define APIs which when called implicitly add to a transaction
created behind the scenes.
Before all that, for cherry-pick I think we should enumerate the cases where
we say "This is a conflict we cannot handle". I think for simplicity we handle
the AppendFile/DeleteFile cases. it becomes trickier when say we do an Update
colA for record1 on main branch, and then we do a update colA to a different
value for record1 on dev-branch. Then when we cherry-pick dev-branch onto main,
we should fail. This is more of a merge semantic, which we're trying to avoid,
but if since we're not directly following git semantics it'll be good to
explicitly outline our desired behavior.
Enumerating those cases, may want to be done in a separate issue so the
community is aligned on what the desired behavior for cherry-pick.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
