eric-maynard commented on code in PR #945:
URL: https://github.com/apache/polaris/pull/945#discussion_r1943763775
##########
polaris-core/src/main/resources/schemas/policies/system/data-compaction/2025-02-03.json:
##########
@@ -0,0 +1,41 @@
+{
+ "license": "Licensed under the Apache License, Version 2.0
(http://www.apache.org/licenses/LICENSE-2.0)",
+ "$id":
"https://polaris.apache.org/schemas/policies/system/data-compaction/2025-02-03.json";,
+ "title": "Data Compaction Policy",
+ "description": "Inheritable Polaris policy schema for Iceberg table data
compaction.",
+ "type": "object",
+ "properties": {
+ "version": {
+ "type": "string",
+ "const": "2025-02-03",
+ "description": "Schema version."
+ },
+ "enable": {
+ "type": "boolean",
+ "description": "Enable or disable data compaction."
+ },
+ "target_file_size_bytes": {
+ "type": "number",
+ "description": "Target data file size in bytes."
+ },
+ "config": {
+ "type": "object",
+ "description": "A map containing custom configuration properties. Please
note that interoperability is not guaranteed.",
Review Comment:
To me this is where the whole thing sort of falls apart. If TMS X and TMS Y
will have different interpretations of the same policy, what's the point of
defining a policy's schema so strictly?
And what if I want to implement TMS Z, which has some new policy type that's
not known by the service. Do I have to fork Polaris and add a new policy
schema? What will other TMSs do when they see this unknown policy?
--
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]
