eric-maynard commented on code in PR #1884:
URL: https://github.com/apache/polaris/pull/1884#discussion_r2144150765
##########
service/common/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogAdapter.java:
##########
@@ -240,7 +242,11 @@ public Response listNamespaces(
@Override
public Response loadNamespaceMetadata(
- String prefix, String namespace, RealmContext realmContext,
SecurityContext securityContext) {
+ String prefix,
+ String namespace,
+ HttpHeaders httpHeaders,
Review Comment:
> Keeps method parameter tuples narrowed down to what is defined in the API
Plus RealmContext and SecurityContext
> Affects only the code that needs to know headers
This sounds like a good alternative but I'm a little unsure how this works.
For example, suppose we add some new feature that relied on a custom header
passed to e.g. loadTable. We would end up injecting the request-scoped bean
into the entire IcebergCatalogAdapter, right? Or is there some way to inject it
just into that method?
> Can be switched on/off in specific builds / deployments without affecting
the main codebase.
Adding the headers here doesn't _functionally_ affect the main codebase, and
if you're talking about a nonfunctional impact (e.g. maintenance cost) then it
sounds like the proposed alternative would still have that impact?
##########
service/common/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogAdapter.java:
##########
@@ -240,7 +242,11 @@ public Response listNamespaces(
@Override
public Response loadNamespaceMetadata(
- String prefix, String namespace, RealmContext realmContext,
SecurityContext securityContext) {
+ String prefix,
+ String namespace,
+ HttpHeaders httpHeaders,
Review Comment:
> Keeps method parameter tuples narrowed down to what is defined in the API
Plus RealmContext and SecurityContext
> Affects only the code that needs to know headers
This sounds like a good alternative but I'm a little unsure how this works.
For example, suppose we add some new feature that relied on a custom header
passed to e.g. loadTable. We would end up injecting the request-scoped bean
into the entire IcebergCatalogAdapter, right? Or is there some way to inject it
just into that method?
> Can be switched on/off in specific builds / deployments without affecting
the main codebase.
Adding the headers here doesn't _functionally_ affect the main codebase, and
if you're talking about a nonfunctional impact (e.g. maintenance cost) then it
sounds like the proposed alternative would still have that impact?
--
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: issues-unsubscr...@polaris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
