dimas-b commented on code in PR #3468:
URL: https://github.com/apache/polaris/pull/3468#discussion_r2705149240
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergRestCatalogEventServiceDelegator.java:
##########
@@ -805,8 +810,41 @@ public Response reportMetrics(
ReportMetricsRequest reportMetricsRequest,
RealmContext realmContext,
SecurityContext securityContext) {
- return delegate.reportMetrics(
- prefix, namespace, table, reportMetricsRequest, realmContext,
securityContext);
+ // Check if metrics event emission is enabled
+ boolean metricsEventEmissionEnabled =
+
realmConfig.getConfig(FeatureConfiguration.ENABLE_METRICS_EVENT_EMISSION);
+
+ // If metrics event emission is disabled, call delegate directly without
emitting events
+ if (!metricsEventEmissionEnabled) {
+ return delegate.reportMetrics(
+ prefix, namespace, table, reportMetricsRequest, realmContext,
securityContext);
+ }
+
+ // Emit events when feature is enabled
+ String catalogName = prefixParser.prefixToCatalogName(realmContext,
prefix);
+ Namespace namespaceObj = decodeNamespace(namespace);
+ polarisEventListener.onEvent(
+ new PolarisEvent(
+ PolarisEventType.BEFORE_REPORT_METRICS,
Review Comment:
Apologies if I missed this in the design doc(s).
Emitting events with the full `reportMetricsRequest` object feels more like
supporting a plugin point for custom event processors.
WDYT about abstracting our a proper metrics processor interface? The default
one would persist metrics to the Polaris database. We could support delegation
via CDI to allow custom processors to be invoked before/after the default one.
My view of Polaris Events is that they are a good vehicle for communicating
with custom code about Polaris code processes, which are essentially controlled
by Polaris (like table changes, etc.). In this case, it looks like we're merely
passing REST API payloads to custom code transparently in a 1-to-1 manner, so
going through events seems to be an unnecessary design complication.
--
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]
