obelix74 commented on code in PR #3385:
URL: https://github.com/apache/polaris/pull/3385#discussion_r2833695952


##########
polaris-core/src/main/java/org/apache/polaris/core/persistence/metrics/MetricsSchemaBootstrap.java:
##########
@@ -0,0 +1,154 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.polaris.core.persistence.metrics;
+
+import com.google.common.annotations.Beta;
+
+/**
+ * Service Provider Interface (SPI) for bootstrapping the metrics schema.
+ *
+ * <p>This interface enables different persistence backends (JDBC, NoSQL, 
custom) to implement
+ * metrics schema initialization in a way appropriate for their storage model. 
The metrics schema is
+ * separate from the entity schema and can be bootstrapped independently.
+ *
+ * <p>Implementations should be idempotent - calling {@link 
#bootstrap(String)} multiple times on
+ * the same realm should have no effect after the first successful call.
+ *
+ * <h3>Dependency Injection</h3>
+ *
+ * <p>This interface is designed to be injected via CDI (Contexts and 
Dependency Injection). The
+ * deployment module should provide a {@code @Produces} method that creates 
the appropriate
+ * implementation based on the configured persistence backend.
+ *
+ * <h3>Usage</h3>
+ *
+ * <p>The metrics schema can be bootstrapped:
+ *
+ * <ul>
+ *   <li>During initial realm bootstrap with the {@code --include-metrics} flag
+ *   <li>Independently via the {@code bootstrap-metrics} CLI command
+ *   <li>Programmatically by injecting this interface and calling {@link 
#bootstrap(String)}
+ * </ul>
+ *
+ * <p><b>Note:</b> This SPI is currently experimental. The API may change in 
future releases.
+ *
+ * @see MetricsPersistence
+ */
+@Beta
+public interface MetricsSchemaBootstrap {

Review Comment:
   Thanks for the suggestion. I considered that approach but kept 
MetricsSchemaBootstrap as a separate interface for a few reasons:
   
   1. Use case difference: MetaStoreManagerFactory.bootstrapRealms() is for 
initial realm creation. MetricsSchemaBootstrap is designed for adding metrics 
to existing realms that were bootstrapped without the --include-metrics flag. 
The standalone bootstrap-metrics CLI command serves operators who want to 
enable metrics on a running deployment without re-bootstrapping.
   
   2. Version management: MetricsSchemaBootstrap provides fine-grained version 
control (getCurrentVersion, getLatestVersion, bootstrap(realm, targetVersion)) 
to support incremental schema upgrades. This lifecycle is different from entity 
schema bootstrap which is typically a one-time operation.
   
   3. Initial bootstrap already works via factory: When using bootstrap 
--include-metrics, the metrics schema is bootstrapped through 
MetaStoreManagerFactory.bootstrapRealms(BootstrapOptions) via 
SchemaOptions.includeMetrics(). So the factory pattern is already used for 
initial setup.
   
   That said, I'm open to alternatives:
   - Add bootstrapMetricsSchema(Iterable<String> realms) to 
MetaStoreManagerFactory with the versioning methods
   - Create a separate MetricsPersistenceFactory that parallels 
MetaStoreManagerFactory
   
   What do you think? Is the current separation acceptable, or would you prefer 
one of the alternatives?  Also, can it be done in a followup PR?



-- 
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]

Reply via email to