eric-maynard commented on code in PR #1284:
URL: https://github.com/apache/polaris/pull/1284#discussion_r2023186360
##########
polaris-core/src/main/resources/schemas/policies/system/snapshot-expiry/2025-02-03.json:
##########
@@ -1,8 +1,8 @@
{
"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/snapshot-retention/2025-02-03.json";,
- "title": "Snapshot Retention Policy",
- "description": "Inheritable Polaris policy schema for Iceberg table snapshot
retention",
+ "$id":
"https://polaris.apache.org/schemas/policies/system/snapshot-expiry/2025-02-03.json";,
+ "title": "Snapshot Expiry Policy",
+ "description": "Inheritable Polaris policy schema for Iceberg table snapshot
expiry",
Review Comment:
It's a little ambiguous. It seems like the intent of the policy is to
determine under what conditions expiry should happen. Similarly, we talk about
masking policies, or compaction policies. Expiry seems marginally more in line
with this, while retention describes the state when no maintenance action is
taken.
Maybe the contention is exactly around the definition of "expire"? If it's
interpreted as something that happens passively, such as when a policy becomes
too old, then I agree calling this an expiry policy doesn't make as much sense.
I was interpreting expire to be used in the same way that Iceberg uses it,
where "expire snapshots" is an action wherein you remove certain snapshots.
##########
polaris-core/src/main/resources/schemas/policies/system/snapshot-expiry/2025-02-03.json:
##########
@@ -1,8 +1,8 @@
{
"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/snapshot-retention/2025-02-03.json";,
- "title": "Snapshot Retention Policy",
- "description": "Inheritable Polaris policy schema for Iceberg table snapshot
retention",
+ "$id":
"https://polaris.apache.org/schemas/policies/system/snapshot-expiry/2025-02-03.json";,
+ "title": "Snapshot Expiry Policy",
+ "description": "Inheritable Polaris policy schema for Iceberg table snapshot
expiry",
Review Comment:
It's a little ambiguous. It seems like the intent of the policy is to
determine under what conditions expiry should happen. Similarly, we talk about
masking policies, or compaction policies. Expiry seems marginally more in line
with this, while retention describes the state when no maintenance action is
taken.
Maybe the contention is around the exact definition of "expire"? If it's
interpreted as something that happens passively, such as when a policy becomes
too old, then I agree calling this an expiry policy doesn't make as much sense.
I was interpreting expire to be used in the same way that Iceberg uses it,
where "expire snapshots" is an action wherein you remove certain snapshots.
--
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]
