singhpk234 commented on code in PR #2714:
URL: https://github.com/apache/polaris/pull/2714#discussion_r2395808219
##########
runtime/service/src/main/java/org/apache/polaris/service/config/ProductionReadinessChecks.java:
##########
@@ -302,4 +302,36 @@ public ProductionReadinessCheck
checkInsecureStorageSettings(
? ProductionReadinessCheck.OK
: ProductionReadinessCheck.of(errors.toArray(new Error[0]));
}
+
+ @Produces
+ public ProductionReadinessCheck checkOverlappingSiblingCheckSettings(
+ FeaturesConfiguration featureConfiguration) {
+ var optimizedSiblingCheck = FeatureConfiguration.OPTIMIZED_SIBLING_CHECK;
+ var errors = new ArrayList<Error>();
+ if
(Boolean.parseBoolean(featureConfiguration.defaults().get(optimizedSiblingCheck.key())))
{
Review Comment:
> Polaris should strive to help users to detect and avoid common pitfalls
(e.g. updating the schema without back-filling data). That we can do via the
"production readiness check", I think.
For this its even tricky, lets say we bootstrap a new realm and we were at
1.0, we will automatically go to schema 2, we don't have realm specific keys
here
https://github.com/apache/polaris/blob/395f7bdc23edd55bc3c33095f258f3026a92478e/persistence/relational-jdbc/src/main/resources/h2/schema-v2.sql#L32C1-L34C27
hence this is a bit tricky IMHO, i think the check you suggested might be
best way out
##########
runtime/service/src/main/java/org/apache/polaris/service/config/ProductionReadinessChecks.java:
##########
@@ -302,4 +302,36 @@ public ProductionReadinessCheck
checkInsecureStorageSettings(
? ProductionReadinessCheck.OK
: ProductionReadinessCheck.of(errors.toArray(new Error[0]));
}
+
+ @Produces
+ public ProductionReadinessCheck checkOverlappingSiblingCheckSettings(
+ FeaturesConfiguration featureConfiguration) {
+ var optimizedSiblingCheck = FeatureConfiguration.OPTIMIZED_SIBLING_CHECK;
+ var errors = new ArrayList<Error>();
+ if
(Boolean.parseBoolean(featureConfiguration.defaults().get(optimizedSiblingCheck.key())))
{
Review Comment:
> Polaris should strive to help users to detect and avoid common pitfalls
(e.g. updating the schema without back-filling data). That we can do via the
"production readiness check", I think.
For this its even tricky, lets say we bootstrap a new realm and we were at
1.0, we will automatically go to schema 2, we don't have realm specific keys
here
https://github.com/apache/polaris/blob/395f7bdc23edd55bc3c33095f258f3026a92478e/persistence/relational-jdbc/src/main/resources/h2/schema-v2.sql#L32C1-L34C27
hence this is a bit tricky IMHO, i think the check you suggested later might
be best way out
--
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]
