[#5370] feat(iceberg): make IcebergTableOperationDispatcher interface more extendable #5369
Conversation
FANNG1
changed the title
|
Do we plan to make similar changes to |
| new IcebergCreateTablePreEvent( | ||
| PrincipalUtils.getCurrentUserName(), nameIdentifier, createTableRequest)); |
There was a problem hiding this comment.
Would it be possible to pass the whole context object inside pre-listener and post listener?
There was a problem hiding this comment.
Could you describe the scenarios?
There was a problem hiding this comment.
Yes, the use case is logging request headers within the event listener.
There was a problem hiding this comment.
Sounds reasonable, @jerryshao WDYT?
There was a problem hiding this comment.
My feeling is that exposing the request header to the event seems not so good, makes the event listener too flexible to do anything. If we want to do check request header check beforehand, maybe we can implement some filters in Jetty, and let Gravitino have the ability to load the custom filters.
There was a problem hiding this comment.
@jerryshao Hi Jerry, I think your idea works for filter checking. What about the use case of headers logging along with table events? How would that look like? Thanks.
yes, will do |
jerryshao
changed the title
What changes were proposed in this pull request?
add
IcebergRequestContextinIcebergTableOperationDispatcherWhy are the changes needed?
Fix: #5370
Does this PR introduce any user-facing change?
No
How was this patch tested?
existing tests