Skip to content

Conversation

@amogh-jahagirdar
Copy link
Contributor

Currently the output of the Spark fast forward procedure always outputs currentSnapshot before and after the fast forward operation. However, this is not correct in case the branch being fast forwarded is not main. This change updates the output to always output the before and after of the actual branch being fast forwarded.

table -> {
long currentRef = table.currentSnapshot().snapshotId();
long currentRef = table.snapshot(source).snapshotId();
table.manageSnapshots().fastForwardBranch(source, target).commit();
Copy link
Contributor Author

@amogh-jahagirdar amogh-jahagirdar Oct 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing to fix....I think when I originally implemented the fastForward operation I switched the definitions of source/target in my head so the API is confusing (in the API, target means the branch that is actually being fast forwarded, source is where target will be moved). That should probably be reversed so target is actually the target to which source will be moved.

I think we should be able to safely just rename the parameters in the API and update the javadoc. Luckily both are String parameters.

cc @rdblue

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I too got confused today when I checked replace branch API vs this procedure variables. Source and target is reversed.

The procedure's named arguments of 'branch' and 'to' is proper. It is like fast forward branch x to y.
Only thing is these internal variables in this procedure is reversed. I think we can rename it in this PR.

ManageSnapshots.replaceBranch and ManageSnapshots.fastForwardBranch seems to have a correct naming IMO

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also agree it is confusing. It would be nice to rename in a follow-up PR or here. It seems like source represents a branch name in this case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put up a separate PR here #9134

@amogh-jahagirdar
Copy link
Contributor Author

also cc @rakesh-das08 let me know your thoughts on this fix!

@amogh-jahagirdar amogh-jahagirdar changed the title Spark: Fix Fast forward before/after snapshot output for non-main branches Spark: Fix Fast forward procedure output for non-main branches Oct 17, 2023
@rakesh-das08
Copy link
Contributor

@amogh-jahagirdar the fix LGTM. Thanks for fixing this.

table -> {
long currentRef = table.currentSnapshot().snapshotId();
long currentRef = table.snapshot(source).snapshotId();
table.manageSnapshots().fastForwardBranch(source, target).commit();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I too got confused today when I checked replace branch API vs this procedure variables. Source and target is reversed.

The procedure's named arguments of 'branch' and 'to' is proper. It is like fast forward branch x to y.
Only thing is these internal variables in this procedure is reversed. I think we can rename it in this PR.

ManageSnapshots.replaceBranch and ManageSnapshots.fastForwardBranch seems to have a correct naming IMO

tableIdent,
table -> {
long currentRef = table.currentSnapshot().snapshotId();
long currentRef = table.snapshot(source).snapshotId();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is also a recent issue reported for fast forward on an empty branch
#8849.

I have analyzed but it looks to be clumsy if we try to support dummy snapshot. Let me know what you guys think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, actually I was investigating that issue and when going through the procedure code I just noticed this issue :) On the dummy snapshot idea, I need to think more. I think that idea has been floated around a few times and it logically makes sense I just don't know all the implications of that change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I also couldn't conclude on the implications. All these days, if the snapshot id is -1, we assume that it is an empty table or just create table happened.

We also need a dummy snapshot id for ancestor check to be passed for fast forward operations.
Nessie uses a constant default hash for on empty branch for handling this kind of ancestor problems. Maybe we need to introduce something like that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had thought of this case where we could introduce a dummy snapshot, but as you mentioned, it did not look like an elegant solution. And with this PR : #7652 , i just basically fall back to the underlying replace operation to throw an appropriate exception.

@ajantha-bhat
Copy link
Member

logged the flaky test: #8855

Copy link
Contributor

@nastra nastra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall LGTM once checkstyle/CI is happy. I would probably also use fast-forward in the error msg

@amogh-jahagirdar
Copy link
Contributor Author

Thanks for the reviews @nastra @rakesh-das08 @ajantha-bhat @aokolnychyi ! I'm going to merge this to keep the fix focused on the procedure output for non-main branches. There are still 2 pending related items:

1.) Fixing the naming in the replace/fastForward APIs: That PR is here https://github.com/apache/iceberg/pull/9134/files
2.) The original issue for fast forwarding a branch which does not exist yet (this PR still preserves the original behavior, just with an explicit null check beforehand).#8849

For 2, I do agree it's an awkward experience that should be fixed (after all many folks would write to audit first before the existence of main). I noticed that recently there was a create added which does add the dummy append. We could maybe stitch together the APIs to achieve the "create" if it does not already exist or we could add a new API. The first is preferable IMO but I'd need to check further on the feasibility.

@amogh-jahagirdar amogh-jahagirdar merged commit 13fcf62 into apache:main Nov 23, 2023
devangjhabakh pushed a commit to cdouglas/iceberg that referenced this pull request Apr 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants