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 which when called
implicitly add to a transaction created behind the scenes. Then when we commit
the SnapshotProducer operation we commit the transaction maintained in the
context. Still pretty vague I know :) ,
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.
We may want to enumerate those cases 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]
