-
Notifications
You must be signed in to change notification settings - Fork 338
Remove *CommitTableEvent, Add *UpdateTableEvent to Transactions #3195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
d6cb781
01b32d7
d9de14c
c0aeb86
07277d2
e44a1de
73b20e8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,7 @@ | |
|
|
||
| package org.apache.polaris.service.catalog.iceberg; | ||
|
|
||
| import com.google.common.annotations.VisibleForTesting; | ||
| import jakarta.annotation.Priority; | ||
| import jakarta.decorator.Decorator; | ||
| import jakarta.decorator.Delegate; | ||
|
|
@@ -34,6 +35,7 @@ | |
| import org.apache.iceberg.rest.requests.RenameTableRequest; | ||
| import org.apache.iceberg.rest.requests.ReportMetricsRequest; | ||
| import org.apache.iceberg.rest.requests.UpdateNamespacePropertiesRequest; | ||
| import org.apache.iceberg.rest.requests.UpdateTableRequest; | ||
| import org.apache.iceberg.rest.responses.CreateNamespaceResponse; | ||
| import org.apache.iceberg.rest.responses.GetNamespaceResponse; | ||
| import org.apache.iceberg.rest.responses.LoadTableResponse; | ||
|
|
@@ -106,6 +108,22 @@ public class IcebergRestCatalogEventServiceDelegator | |
| @Inject PolarisEventMetadataFactory eventMetadataFactory; | ||
| @Inject CatalogPrefixParser prefixParser; | ||
|
|
||
| // Constructor for testing - allows manual dependency injection | ||
| @VisibleForTesting | ||
| public IcebergRestCatalogEventServiceDelegator( | ||
| IcebergCatalogAdapter delegate, | ||
| PolarisEventListener polarisEventListener, | ||
| PolarisEventMetadataFactory eventMetadataFactory, | ||
| CatalogPrefixParser prefixParser) { | ||
| this.delegate = delegate; | ||
| this.polarisEventListener = polarisEventListener; | ||
| this.eventMetadataFactory = eventMetadataFactory; | ||
| this.prefixParser = prefixParser; | ||
| } | ||
|
|
||
| // Default constructor for CDI | ||
| public IcebergRestCatalogEventServiceDelegator() {} | ||
|
|
||
| @Override | ||
| public Response createNamespace( | ||
| String prefix, | ||
|
|
@@ -597,11 +615,30 @@ public Response commitTransaction( | |
| polarisEventListener.onBeforeCommitTransaction( | ||
| new IcebergRestCatalogEvents.BeforeCommitTransactionEvent( | ||
| eventMetadataFactory.create(), catalogName, commitTransactionRequest)); | ||
| for (UpdateTableRequest req : commitTransactionRequest.tableChanges()) { | ||
| polarisEventListener.onBeforeUpdateTable( | ||
| new BeforeUpdateTableEvent( | ||
| eventMetadataFactory.create(), | ||
| catalogName, | ||
| req.identifier().namespace(), | ||
| req.identifier().name(), | ||
| req)); | ||
| } | ||
| Response resp = | ||
| delegate.commitTransaction(prefix, commitTransactionRequest, realmContext, securityContext); | ||
| polarisEventListener.onAfterCommitTransaction( | ||
| new IcebergRestCatalogEvents.AfterCommitTransactionEvent( | ||
| eventMetadataFactory.create(), catalogName, commitTransactionRequest)); | ||
| for (UpdateTableRequest req : commitTransactionRequest.tableChanges()) { | ||
| polarisEventListener.onAfterUpdateTable( | ||
| new AfterUpdateTableEvent( | ||
| eventMetadataFactory.create(), | ||
| catalogName, | ||
| req.identifier().namespace(), | ||
| req.identifier().name(), | ||
| req, | ||
| null)); | ||
| } | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this is the right behavior for multi-table transactions. Emitting AfterUpdateTableEvent only after the entire transaction succeeds ensures the correct semantics and avoids exposing partial state. Thanks for making this change. If there’s interest in finer-grained events for multi-table transactions (e.g., per-table events that fire even before the full transaction commits), we could explore that as a follow-up discussion. Here is the related dev ML discussion: https://lists.apache.org/thread/5og0qjo8l9rf0kytqjg4gn7d9r81gf79. Can we add tests for this new logic?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added the test! |
||
| return resp; | ||
| } | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -125,8 +125,8 @@ public enum PolarisEventType { | |
| AFTER_RENAME_TABLE, | ||
| BEFORE_UPDATE_TABLE, | ||
| AFTER_UPDATE_TABLE, | ||
| BEFORE_COMMIT_TABLE, | ||
| AFTER_COMMIT_TABLE, | ||
| BEFORE_COMMIT_TABLE, // REMOVED FROM SOURCE CODE | ||
| AFTER_COMMIT_TABLE, // REMOVED FROM SOURCE CODE | ||
|
Comment on lines
+128
to
+129
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we remove them as there is no usage?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe that will change the ordinal numbers of the enum and so I'm avoiding doing that. Given Events are still in "preview" we have the ability to do so without any prior notice - but just being careful. Let me know what you think.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a valid concern. I'm OK to remove it as this is preview feature, but it requires notice. Another option is to adding code field to explicitly set a number for the type. This is more robust so that it prevents any developer adding an event in the middle and accidentally break downstreams. It isn't a blocker for this PR though. Can you file an issue for this? Something like: Adding a constructor will prevent accidental ordinal changes and make future evolution safer. Given the downstream relies on the event type, I think it's reasonable to add a explicit code.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, sounds good! I will open the issue! |
||
| BEFORE_REFRESH_TABLE, | ||
| AFTER_REFRESH_TABLE, | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar events emitted from
updateTablehave a value for the last parameter (LoadTableResponse), but here it isnull.It that parameter useful to the consumer when it is not available in all situations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented about this earlier: #3195 (comment)
We should get back to the state where this is not null soon. But for that, we will have to solve the larger issue in #3209. I think it is fine to keep this code for now and get back to working on #3209 (hopefully in the near future) to fix this
null.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for missing the earlier comment 🤦
If our intention is to provide the same set of parameters (non-null) to events of the same type in all situations, then given that this PR deviates from that goal, I believe we ought to mark this on the javadoc of AfterUpdateTableEvent at least.
A CHANGELOG entry is not required, IMHO, since it's developer-level change at this stage.
That said, the plan SGTM 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal preference would be to remove
LoadTableResponsefromAfterUpdateTableEventin this PR (in all cases) and re-add when we can provide it in all contexts. I think it would provide a more coherent migration path from the consumer's POV.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fair too. I was trying to reduce the amount of changes to the event structure itself and use the fact that this is null (only in the case of transactions, to be clear) to place urgency in trying to fix #3209. I'll make the change for the Javadoc - let me know if removing the LoadTableResponse is a blocking concern for you. Else, I'd prefer to keep this approach the way it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thx - LGTM 👍