This is an automated email from the ASF dual-hosted git repository.
yufei pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/polaris.git
The following commit(s) were added to refs/heads/main by this push:
new e91d2c32e Downgrade open api generator to 7.11 (#1823)
e91d2c32e is described below
commit e91d2c32ec39b9a4bb28fc2833a33990395f5601
Author: Honah (Jonas) J. <hon...@apache.org>
AuthorDate: Fri Jun 6 09:56:20 2025 -0700
Downgrade open api generator to 7.11 (#1823)
---
client/python/.openapi-generator/VERSION | 2 +-
client/python/README.md | 2 +-
client/python/docs/CatalogAPI.md | 36 ++--------
client/python/docs/ConfigurationAPI.md | 26 +------
client/python/docs/GenericTableAPI.md | 3 +-
client/python/docs/IcebergCatalogAPI.md | 86 +++--------------------
client/python/docs/IcebergConfigurationAPI.md | 26 +------
client/python/docs/IcebergOAuth2API.md | 18 +----
client/python/docs/OAuth2API.md | 18 +----
client/python/docs/PolarisDefaultApi.md | 64 +++++++++++++++++
client/python/docs/PolicyAPI.md | 81 ++-------------------
client/python/polaris/catalog/configuration.py | 11 +--
client/python/polaris/catalog/rest.py | 1 -
client/python/polaris/management/configuration.py | 11 +--
client/python/polaris/management/rest.py | 1 -
client/templates/regenerate.sh | 3 +-
16 files changed, 99 insertions(+), 290 deletions(-)
diff --git a/client/python/.openapi-generator/VERSION
b/client/python/.openapi-generator/VERSION
index 5f84a81db..b23eb2752 100644
--- a/client/python/.openapi-generator/VERSION
+++ b/client/python/.openapi-generator/VERSION
@@ -1 +1 @@
-7.12.0
+7.11.0
diff --git a/client/python/README.md b/client/python/README.md
index 1c20c12c5..a79b8d241 100644
--- a/client/python/README.md
+++ b/client/python/README.md
@@ -25,7 +25,7 @@ This Python package is automatically generated by the
[OpenAPI Generator](https:
- API version: 0.0.1
- Package version: 1.0.0
-- Generator version: 7.12.0
+- Generator version: 7.11.0
- Build package: org.openapitools.codegen.languages.PythonClientCodegen
## Requirements.
diff --git a/client/python/docs/CatalogAPI.md b/client/python/docs/CatalogAPI.md
index 407b53b2c..e997a5a6e 100644
--- a/client/python/docs/CatalogAPI.md
+++ b/client/python/docs/CatalogAPI.md
@@ -238,11 +238,7 @@ Name | Type | Description | Notes
Create a table in the given namespace
-Create a table or start a create transaction, like atomic CTAS.
-
-If `stage-create` is false, the table is created immediately.
-
-If `stage-create` is true, the table is not created, but table metadata is
initialized and returned. The service should prepare as needed for a commit to
the table commit endpoint to complete the create transaction. The client uses
the returned metadata to begin a transaction. To commit the transaction, the
client sends all create and subsequent changes to the table commit route.
Changes from the table create operation include changes like AddSchemaUpdate
and SetCurrentSchemaUpdate that [...]
+Create a table or start a create transaction, like atomic CTAS. If
`stage-create` is false, the table is created immediately. If `stage-create`
is true, the table is not created, but table metadata is initialized and
returned. The service should prepare as needed for a commit to the table commit
endpoint to complete the create transaction. The client uses the returned
metadata to begin a transaction. To commit the transaction, the client sends
all create and subsequent changes to the t [...]
### Example
@@ -697,7 +693,7 @@ void (empty response body)
List namespaces, optionally providing a parent namespace to list underneath
-List all namespaces at a certain level, optionally starting from a given
parent namespace. If table accounting.tax.paid.info exists, using 'SELECT
NAMESPACE IN accounting' would translate into `GET
/namespaces?parent=accounting` and must return a namespace, ["accounting",
"tax"] only. Using 'SELECT NAMESPACE IN accounting.tax' would translate into
`GET /namespaces?parent=accounting%1Ftax` and must return a namespace,
["accounting", "tax", "paid"]. If `parent` is not provided, all top-lev [...]
+List all namespaces at a certain level, optionally starting from a given
parent namespace. If table accounting.tax.paid.info exists, using 'SELECT
NAMESPACE IN accounting' would translate into `GET
/namespaces?parent=accounting` and must return a namespace, [\"accounting\",
\"tax\"] only. Using 'SELECT NAMESPACE IN accounting.tax' would translate into
`GET /namespaces?parent=accounting%1Ftax` and must return a namespace,
[\"accounting\", \"tax\", \"paid\"]. If `parent` is not provided, a [...]
### Example
@@ -1161,13 +1157,7 @@ Name | Type | Description | Notes
Load a table from the catalog
-Load a table from the catalog.
-
-The response contains both configuration and table metadata. The
configuration, if non-empty is used as additional configuration for the table
that overrides catalog configuration. For example, this configuration may
change the FileIO implementation to be used for the table.
-
-The response also contains the table's full metadata, matching the table
metadata JSON file.
-
-The catalog configuration may contain credentials that should be used for
subsequent requests for the table. The configuration key "token" is used to
pass an access token to be used as a bearer token for table requests.
Otherwise, a token may be passed using a RFC 8693 token type as a configuration
key. For example, "urn:ietf:params:oauth:token-type:jwt=<JWT-token>".
+Load a table from the catalog. The response contains both configuration and
table metadata. The configuration, if non-empty is used as additional
configuration for the table that overrides catalog configuration. For example,
this configuration may change the FileIO implementation to be used for the
table. The response also contains the table's full metadata, matching the
table metadata JSON file. The catalog configuration may contain credentials
that should be used for subsequent requ [...]
### Example
@@ -1266,13 +1256,7 @@ Name | Type | Description | Notes
Load a view from the catalog
-Load a view from the catalog.
-
-The response contains both configuration and view metadata. The configuration,
if non-empty is used as additional configuration for the view that overrides
catalog configuration.
-
-The response also contains the view's full metadata, matching the view
metadata JSON file.
-
-The catalog configuration may contain credentials that should be used for
subsequent requests for the view. The configuration key "token" is used to pass
an access token to be used as a bearer token for view requests. Otherwise, a
token may be passed using a RFC 8693 token type as a configuration key. For
example, "urn:ietf:params:oauth:token-type:jwt=<JWT-token>".
+Load a view from the catalog. The response contains both configuration and
view metadata. The configuration, if non-empty is used as additional
configuration for the view that overrides catalog configuration. The response
also contains the view's full metadata, matching the view metadata JSON file.
The catalog configuration may contain credentials that should be used for
subsequent requests for the view. The configuration key \"token\" is used to
pass an access token to be used as a b [...]
### Example
@@ -2094,9 +2078,7 @@ void (empty response body)
Set or remove properties on a namespace
-Set and/or remove properties on a namespace. The request body specifies a list
of properties to remove and a map of key value pairs to update.
-Properties that are not in the request are not modified or removed by this
call.
-Server implementations are not required to support namespace properties.
+Set and/or remove properties on a namespace. The request body specifies a list
of properties to remove and a map of key value pairs to update. Properties that
are not in the request are not modified or removed by this call. Server
implementations are not required to support namespace properties.
### Example
@@ -2191,13 +2173,7 @@ Name | Type | Description | Notes
Commit updates to a table
-Commit updates to a table.
-
-Commits have two parts, requirements and updates. Requirements are assertions
that will be validated before attempting to make and commit changes. For
example, `assert-ref-snapshot-id` will check that a named ref's snapshot ID has
a certain value. Server implementations are required to fail with a 400 status
code if any unknown updates or requirements are received.
-
-Updates are changes to make to table metadata. For example, after asserting
that the current main ref is at the expected snapshot, a commit may add a new
child snapshot and set the ref to the new snapshot id.
-
-Create table transactions that are started by createTable with `stage-create`
set to true are committed using this route. Transactions should include all
changes to the table, including table initialization, like AddSchemaUpdate and
SetCurrentSchemaUpdate. The `assert-create` requirement is used to ensure that
the table was not created concurrently.
+Commit updates to a table. Commits have two parts, requirements and updates.
Requirements are assertions that will be validated before attempting to make
and commit changes. For example, `assert-ref-snapshot-id` will check that a
named ref's snapshot ID has a certain value. Server implementations are
required to fail with a 400 status code if any unknown updates or requirements
are received. Updates are changes to make to table metadata. For example,
after asserting that the current ma [...]
### Example
diff --git a/client/python/docs/ConfigurationAPI.md
b/client/python/docs/ConfigurationAPI.md
index 0794cd971..448ce0f86 100644
--- a/client/python/docs/ConfigurationAPI.md
+++ b/client/python/docs/ConfigurationAPI.md
@@ -32,31 +32,7 @@ Method | HTTP request | Description
List all catalog configuration settings
- All REST clients should first call this route to get catalog configuration
properties from the server to configure the catalog and its HTTP client.
Configuration from the server consists of two sets of key/value pairs.
-- defaults - properties that should be used as default configuration; applied
before client configuration
-- overrides - properties that should be used to override client configuration;
applied after defaults and client configuration
-
-Catalog configuration is constructed by setting the defaults, then client-
provided configuration, and finally overrides. The final property set is then
used to configure the catalog.
-
-For example, a default configuration property might set the size of the client
pool, which can be replaced with a client-specific setting. An override might
be used to set the warehouse location, which is stored on the server rather
than in client configuration.
-
-Common catalog configuration settings are documented at
https://iceberg.apache.org/docs/latest/configuration/#catalog-properties
-
-The catalog configuration also holds an optional `endpoints` field that
contains information about the endpoints supported by the server. If a server
does not send the `endpoints` field, a default set of endpoints is assumed:
-- GET /v1/{prefix}/namespaces
-- POST /v1/{prefix}/namespaces
-- GET /v1/{prefix}/namespaces/{namespace}
-- DELETE /v1/{prefix}/namespaces/{namespace}
-- POST /v1/{prefix}/namespaces/{namespace}/properties
-- GET /v1/{prefix}/namespaces/{namespace}/tables
-- POST /v1/{prefix}/namespaces/{namespace}/tables
-- GET /v1/{prefix}/namespaces/{namespace}/tables/{table}
-- POST /v1/{prefix}/namespaces/{namespace}/tables/{table}
-- DELETE /v1/{prefix}/namespaces/{namespace}/tables/{table}
-- POST /v1/{prefix}/namespaces/{namespace}/register
-- POST /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics
-- POST /v1/{prefix}/tables/rename
-- POST /v1/{prefix}/transactions/commit
+ All REST clients should first call this route to get catalog configuration
properties from the server to configure the catalog and its HTTP client.
Configuration from the server consists of two sets of key/value pairs. -
defaults - properties that should be used as default configuration; applied
before client configuration - overrides - properties that should be used to
override client configuration; applied after defaults and client configuration
Catalog configuration is constructed [...]
### Example
diff --git a/client/python/docs/GenericTableAPI.md
b/client/python/docs/GenericTableAPI.md
index 5e5957c16..658c9a49e 100644
--- a/client/python/docs/GenericTableAPI.md
+++ b/client/python/docs/GenericTableAPI.md
@@ -309,8 +309,7 @@ Name | Type | Description | Notes
Load a generic table under the given namespace from the catalog
-Load a generic table from the catalog under the given namespace.
-The response contains all table information passed during create.
+Load a generic table from the catalog under the given namespace. The response
contains all table information passed during create.
### Example
diff --git a/client/python/docs/IcebergCatalogAPI.md
b/client/python/docs/IcebergCatalogAPI.md
index 44c526dd5..a90cc387f 100644
--- a/client/python/docs/IcebergCatalogAPI.md
+++ b/client/python/docs/IcebergCatalogAPI.md
@@ -59,15 +59,7 @@ Method | HTTP request | Description
Cancels scan planning for a plan-id
-Cancels scan planning for a plan-id.
-
-This notifies the service that it can release resources held for the scan.
Clients should cancel scans that are no longer needed, either while the plan-id
returns a "submitted" status or while there are remaining plan tasks that have
not been fetched.
-
-Cancellation is not necessary when
-- Scan tasks for each plan task have been fetched using fetchScanTasks
-- A plan-id has produced a "failed" or "cancelled" status from
- planTableScan or fetchPlanningResult
-
+Cancels scan planning for a plan-id. This notifies the service that it can
release resources held for the scan. Clients should cancel scans that are no
longer needed, either while the plan-id returns a \"submitted\" status or while
there are remaining plan tasks that have not been fetched. Cancellation is not
necessary when - Scan tasks for each plan task have been fetched using
fetchScanTasks - A plan-id has produced a \"failed\" or \"cancelled\" status
from planTableScan or fetchPl [...]
### Example
@@ -340,11 +332,7 @@ Name | Type | Description | Notes
Create a table in the given namespace
-Create a table or start a create transaction, like atomic CTAS.
-
-If `stage-create` is false, the table is created immediately.
-
-If `stage-create` is true, the table is not created, but table metadata is
initialized and returned. The service should prepare as needed for a commit to
the table commit endpoint to complete the create transaction. The client uses
the returned metadata to begin a transaction. To commit the transaction, the
client sends all create and subsequent changes to the table commit route.
Changes from the table create operation include changes like AddSchemaUpdate
and SetCurrentSchemaUpdate that [...]
+Create a table or start a create transaction, like atomic CTAS. If
`stage-create` is false, the table is created immediately. If `stage-create`
is true, the table is not created, but table metadata is initialized and
returned. The service should prepare as needed for a commit to the table commit
endpoint to complete the create transaction. The client uses the returned
metadata to begin a transaction. To commit the transaction, the client sends
all create and subsequent changes to the t [...]
### Example
@@ -799,20 +787,7 @@ void (empty response body)
Fetches the result of scan planning for a plan-id
-Fetches the result of scan planning for a plan-id.
-
-Responses must include a valid status
-- When "completed" the planning operation has produced plan-tasks and
- file-scan-tasks that must be returned in the response
-
-- When "submitted" the planning operation has not completed; the client
- should wait to call this endpoint again to fetch a completed response
-
-- When "failed" the response must be a valid error response
-- When "cancelled" the plan-id is invalid and should be discarded
-
-The response for a "completed" planning operation includes two types of tasks
(file scan tasks and plan tasks) and both may be included in the response.
Tasks must not be included for any other response status.
-
+Fetches the result of scan planning for a plan-id. Responses must include a
valid status - When \"completed\" the planning operation has produced
plan-tasks and file-scan-tasks that must be returned in the response - When
\"submitted\" the planning operation has not completed; the client should
wait to call this endpoint again to fetch a completed response - When
\"failed\" the response must be a valid error response - When \"cancelled\" the
plan-id is invalid and should be discar [...]
### Example
@@ -1001,7 +976,7 @@ Name | Type | Description | Notes
List namespaces, optionally providing a parent namespace to list underneath
-List all namespaces at a certain level, optionally starting from a given
parent namespace. If table accounting.tax.paid.info exists, using 'SELECT
NAMESPACE IN accounting' would translate into `GET
/namespaces?parent=accounting` and must return a namespace, ["accounting",
"tax"] only. Using 'SELECT NAMESPACE IN accounting.tax' would translate into
`GET /namespaces?parent=accounting%1Ftax` and must return a namespace,
["accounting", "tax", "paid"]. If `parent` is not provided, all top-lev [...]
+List all namespaces at a certain level, optionally starting from a given
parent namespace. If table accounting.tax.paid.info exists, using 'SELECT
NAMESPACE IN accounting' would translate into `GET
/namespaces?parent=accounting` and must return a namespace, [\"accounting\",
\"tax\"] only. Using 'SELECT NAMESPACE IN accounting.tax' would translate into
`GET /namespaces?parent=accounting%1Ftax` and must return a namespace,
[\"accounting\", \"tax\", \"paid\"]. If `parent` is not provided, a [...]
### Example
@@ -1465,13 +1440,7 @@ Name | Type | Description | Notes
Load a table from the catalog
-Load a table from the catalog.
-
-The response contains both configuration and table metadata. The
configuration, if non-empty is used as additional configuration for the table
that overrides catalog configuration. For example, this configuration may
change the FileIO implementation to be used for the table.
-
-The response also contains the table's full metadata, matching the table
metadata JSON file.
-
-The catalog configuration may contain credentials that should be used for
subsequent requests for the table. The configuration key "token" is used to
pass an access token to be used as a bearer token for table requests.
Otherwise, a token may be passed using a RFC 8693 token type as a configuration
key. For example, "urn:ietf:params:oauth:token-type:jwt=<JWT-token>".
+Load a table from the catalog. The response contains both configuration and
table metadata. The configuration, if non-empty is used as additional
configuration for the table that overrides catalog configuration. For example,
this configuration may change the FileIO implementation to be used for the
table. The response also contains the table's full metadata, matching the
table metadata JSON file. The catalog configuration may contain credentials
that should be used for subsequent requ [...]
### Example
@@ -1570,13 +1539,7 @@ Name | Type | Description | Notes
Load a view from the catalog
-Load a view from the catalog.
-
-The response contains both configuration and view metadata. The configuration,
if non-empty is used as additional configuration for the view that overrides
catalog configuration.
-
-The response also contains the view's full metadata, matching the view
metadata JSON file.
-
-The catalog configuration may contain credentials that should be used for
subsequent requests for the view. The configuration key "token" is used to pass
an access token to be used as a bearer token for view requests. Otherwise, a
token may be passed using a RFC 8693 token type as a configuration key. For
example, "urn:ietf:params:oauth:token-type:jwt=<JWT-token>".
+Load a view from the catalog. The response contains both configuration and
view metadata. The configuration, if non-empty is used as additional
configuration for the view that overrides catalog configuration. The response
also contains the view's full metadata, matching the view metadata JSON file.
The catalog configuration may contain credentials that should be used for
subsequent requests for the view. The configuration key \"token\" is used to
pass an access token to be used as a b [...]
### Example
@@ -1755,30 +1718,7 @@ void (empty response body)
Submit a scan for planning
-Submits a scan for server-side planning.
-
-Point-in-time scans are planned by passing snapshot-id to identify the table
snapshot to scan. Incremental scans are planned by passing both
start-snapshot-id and end-snapshot-id. Requests that include both point in time
config properties and incremental config properties are invalid. If the request
does not include either incremental or point-in-time config properties, scan
planning should produce a point-in-time scan of the latest snapshot in the
table's main branch.
-
-Responses must include a valid status listed below. A "cancelled" status is
considered invalid for this endpoint.
-- When "completed" the planning operation has produced plan tasks and
- file scan tasks that must be returned in the response (not fetched
- later by calling fetchPlanningResult)
-
-- When "submitted" the response must include a plan-id used to poll
- fetchPlanningResult to fetch the planning result when it is ready
-
-- When "failed" the response must be a valid error response
-The response for a "completed" planning operation includes two types of tasks
(file scan tasks and plan tasks) and both may be included in the response.
Tasks must not be included for any other response status.
-
-Responses that include a plan-id indicate that the service is holding state or
performing work for the client.
-
-- Clients should use the plan-id to fetch results from
- fetchPlanningResult when the response status is "submitted"
-
-- Clients should inform the service if planning results are no longer
- needed by calling cancelPlanning. Cancellation is not necessary after
- fetchScanTasks has been used to fetch scan tasks for each plan task.
-
+Submits a scan for server-side planning. Point-in-time scans are planned by
passing snapshot-id to identify the table snapshot to scan. Incremental scans
are planned by passing both start-snapshot-id and end-snapshot-id. Requests
that include both point in time config properties and incremental config
properties are invalid. If the request does not include either incremental or
point-in-time config properties, scan planning should produce a point-in-time
scan of the latest snapshot in t [...]
### Example
@@ -2426,9 +2366,7 @@ void (empty response body)
Set or remove properties on a namespace
-Set and/or remove properties on a namespace. The request body specifies a list
of properties to remove and a map of key value pairs to update.
-Properties that are not in the request are not modified or removed by this
call.
-Server implementations are not required to support namespace properties.
+Set and/or remove properties on a namespace. The request body specifies a list
of properties to remove and a map of key value pairs to update. Properties that
are not in the request are not modified or removed by this call. Server
implementations are not required to support namespace properties.
### Example
@@ -2523,13 +2461,7 @@ Name | Type | Description | Notes
Commit updates to a table
-Commit updates to a table.
-
-Commits have two parts, requirements and updates. Requirements are assertions
that will be validated before attempting to make and commit changes. For
example, `assert-ref-snapshot-id` will check that a named ref's snapshot ID has
a certain value. Server implementations are required to fail with a 400 status
code if any unknown updates or requirements are received.
-
-Updates are changes to make to table metadata. For example, after asserting
that the current main ref is at the expected snapshot, a commit may add a new
child snapshot and set the ref to the new snapshot id.
-
-Create table transactions that are started by createTable with `stage-create`
set to true are committed using this route. Transactions should include all
changes to the table, including table initialization, like AddSchemaUpdate and
SetCurrentSchemaUpdate. The `assert-create` requirement is used to ensure that
the table was not created concurrently.
+Commit updates to a table. Commits have two parts, requirements and updates.
Requirements are assertions that will be validated before attempting to make
and commit changes. For example, `assert-ref-snapshot-id` will check that a
named ref's snapshot ID has a certain value. Server implementations are
required to fail with a 400 status code if any unknown updates or requirements
are received. Updates are changes to make to table metadata. For example,
after asserting that the current ma [...]
### Example
diff --git a/client/python/docs/IcebergConfigurationAPI.md
b/client/python/docs/IcebergConfigurationAPI.md
index 09214de89..eaada8968 100644
--- a/client/python/docs/IcebergConfigurationAPI.md
+++ b/client/python/docs/IcebergConfigurationAPI.md
@@ -32,31 +32,7 @@ Method | HTTP request | Description
List all catalog configuration settings
- All REST clients should first call this route to get catalog configuration
properties from the server to configure the catalog and its HTTP client.
Configuration from the server consists of two sets of key/value pairs.
-- defaults - properties that should be used as default configuration; applied
before client configuration
-- overrides - properties that should be used to override client configuration;
applied after defaults and client configuration
-
-Catalog configuration is constructed by setting the defaults, then client-
provided configuration, and finally overrides. The final property set is then
used to configure the catalog.
-
-For example, a default configuration property might set the size of the client
pool, which can be replaced with a client-specific setting. An override might
be used to set the warehouse location, which is stored on the server rather
than in client configuration.
-
-Common catalog configuration settings are documented at
https://iceberg.apache.org/docs/latest/configuration/#catalog-properties
-
-The catalog configuration also holds an optional `endpoints` field that
contains information about the endpoints supported by the server. If a server
does not send the `endpoints` field, a default set of endpoints is assumed:
-- GET /v1/{prefix}/namespaces
-- POST /v1/{prefix}/namespaces
-- GET /v1/{prefix}/namespaces/{namespace}
-- DELETE /v1/{prefix}/namespaces/{namespace}
-- POST /v1/{prefix}/namespaces/{namespace}/properties
-- GET /v1/{prefix}/namespaces/{namespace}/tables
-- POST /v1/{prefix}/namespaces/{namespace}/tables
-- GET /v1/{prefix}/namespaces/{namespace}/tables/{table}
-- POST /v1/{prefix}/namespaces/{namespace}/tables/{table}
-- DELETE /v1/{prefix}/namespaces/{namespace}/tables/{table}
-- POST /v1/{prefix}/namespaces/{namespace}/register
-- POST /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics
-- POST /v1/{prefix}/tables/rename
-- POST /v1/{prefix}/transactions/commit
+ All REST clients should first call this route to get catalog configuration
properties from the server to configure the catalog and its HTTP client.
Configuration from the server consists of two sets of key/value pairs. -
defaults - properties that should be used as default configuration; applied
before client configuration - overrides - properties that should be used to
override client configuration; applied after defaults and client configuration
Catalog configuration is constructed [...]
### Example
diff --git a/client/python/docs/IcebergOAuth2API.md
b/client/python/docs/IcebergOAuth2API.md
index 581c2e8e7..b93d99b32 100644
--- a/client/python/docs/IcebergOAuth2API.md
+++ b/client/python/docs/IcebergOAuth2API.md
@@ -32,23 +32,7 @@ Method | HTTP request | Description
Get a token using an OAuth2 flow (DEPRECATED for REMOVAL)
-The `oauth/tokens` endpoint is **DEPRECATED for REMOVAL**. It is _not_
recommended to implement this endpoint, unless you are fully aware of the
potential security implications.
-All clients are encouraged to explicitly set the configuration property
`oauth2-server-uri` to the correct OAuth endpoint.
-Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be
removed from this spec in Iceberg (Java) 2.0.
-See [Security improvements in the Iceberg REST
specification](https://github.com/apache/iceberg/issues/10537)
-
-Exchange credentials for a token using the OAuth2 client credentials flow or
token exchange.
-
-This endpoint is used for three purposes -
-1. To exchange client credentials (client ID and secret) for an access token
This uses the client credentials flow.
-2. To exchange a client token and an identity token for a more specific access
token This uses the token exchange flow.
-3. To exchange an access token for one with the same claims and a refreshed
expiration period This uses the token exchange flow.
-
-For example, a catalog client may be configured with client credentials from
the OAuth2 Authorization flow. This client would exchange its client ID and
secret for an access token using the client credentials request with this
endpoint (1). Subsequent requests would then use that access token.
-
-Some clients may also handle sessions that have additional user context. These
clients would use the token exchange flow to exchange a user token (the
"subject" token) from the session for a more specific access token for that
user, using the catalog's access token as the "actor" token (2). The user ID
token is the "subject" token and can be any token type allowed by the OAuth2
token exchange flow, including a unsecured JWT token with a sub claim. This
request should use the catalog's be [...]
-
-Clients may also use the token exchange flow to refresh a token that is about
to expire by sending a token exchange request (3). The request's "subject"
token should be the expiring token. This request should use the subject token
in the "Authorization" header.
+The `oauth/tokens` endpoint is **DEPRECATED for REMOVAL**. It is _not_
recommended to implement this endpoint, unless you are fully aware of the
potential security implications. All clients are encouraged to explicitly set
the configuration property `oauth2-server-uri` to the correct OAuth endpoint.
Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be
removed from this spec in Iceberg (Java) 2.0. See [Security improvements in the
Iceberg REST specification](https [...]
### Example
diff --git a/client/python/docs/OAuth2API.md b/client/python/docs/OAuth2API.md
index cad1050b9..9e25d433b 100644
--- a/client/python/docs/OAuth2API.md
+++ b/client/python/docs/OAuth2API.md
@@ -32,23 +32,7 @@ Method | HTTP request | Description
Get a token using an OAuth2 flow (DEPRECATED for REMOVAL)
-The `oauth/tokens` endpoint is **DEPRECATED for REMOVAL**. It is _not_
recommended to implement this endpoint, unless you are fully aware of the
potential security implications.
-All clients are encouraged to explicitly set the configuration property
`oauth2-server-uri` to the correct OAuth endpoint.
-Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be
removed from this spec in Iceberg (Java) 2.0.
-See [Security improvements in the Iceberg REST
specification](https://github.com/apache/iceberg/issues/10537)
-
-Exchange credentials for a token using the OAuth2 client credentials flow or
token exchange.
-
-This endpoint is used for three purposes -
-1. To exchange client credentials (client ID and secret) for an access token
This uses the client credentials flow.
-2. To exchange a client token and an identity token for a more specific access
token This uses the token exchange flow.
-3. To exchange an access token for one with the same claims and a refreshed
expiration period This uses the token exchange flow.
-
-For example, a catalog client may be configured with client credentials from
the OAuth2 Authorization flow. This client would exchange its client ID and
secret for an access token using the client credentials request with this
endpoint (1). Subsequent requests would then use that access token.
-
-Some clients may also handle sessions that have additional user context. These
clients would use the token exchange flow to exchange a user token (the
"subject" token) from the session for a more specific access token for that
user, using the catalog's access token as the "actor" token (2). The user ID
token is the "subject" token and can be any token type allowed by the OAuth2
token exchange flow, including a unsecured JWT token with a sub claim. This
request should use the catalog's be [...]
-
-Clients may also use the token exchange flow to refresh a token that is about
to expire by sending a token exchange request (3). The request's "subject"
token should be the expiring token. This request should use the subject token
in the "Authorization" header.
+The `oauth/tokens` endpoint is **DEPRECATED for REMOVAL**. It is _not_
recommended to implement this endpoint, unless you are fully aware of the
potential security implications. All clients are encouraged to explicitly set
the configuration property `oauth2-server-uri` to the correct OAuth endpoint.
Deprecated since Iceberg (Java) 1.6.0. The endpoint and related types will be
removed from this spec in Iceberg (Java) 2.0. See [Security improvements in the
Iceberg REST specification](https [...]
### Example
diff --git a/client/python/docs/PolarisDefaultApi.md
b/client/python/docs/PolarisDefaultApi.md
index e18141dc5..533cbe99a 100644
--- a/client/python/docs/PolarisDefaultApi.md
+++ b/client/python/docs/PolarisDefaultApi.md
@@ -61,6 +61,8 @@ Method | HTTP request | Description
# **add_grant_to_catalog_role**
> add_grant_to_catalog_role(catalog_name, catalog_role_name,
> add_grant_request=add_grant_request)
+
+
Add a new grant to the catalog role
### Example
@@ -137,6 +139,8 @@ void (empty response body)
# **assign_catalog_role_to_principal_role**
> assign_catalog_role_to_principal_role(principal_role_name, catalog_name,
> grant_catalog_role_request)
+
+
Assign a catalog role to a principal role
### Example
@@ -212,6 +216,8 @@ void (empty response body)
# **assign_principal_role**
> assign_principal_role(principal_name, grant_principal_role_request)
+
+
Add a role to the principal
### Example
@@ -286,6 +292,8 @@ void (empty response body)
# **create_catalog**
> create_catalog(create_catalog_request)
+
+
Add a new Catalog
### Example
@@ -359,6 +367,8 @@ void (empty response body)
# **create_catalog_role**
> create_catalog_role(catalog_name,
> create_catalog_role_request=create_catalog_role_request)
+
+
Create a new role in the catalog
### Example
@@ -433,6 +443,8 @@ void (empty response body)
# **create_principal**
> PrincipalWithCredentials create_principal(create_principal_request)
+
+
Create a principal
### Example
@@ -507,6 +519,8 @@ Name | Type | Description | Notes
# **create_principal_role**
> create_principal_role(create_principal_role_request)
+
+
Create a principal role
### Example
@@ -578,6 +592,8 @@ void (empty response body)
# **delete_catalog**
> delete_catalog(catalog_name)
+
+
Delete an existing catalog. The catalog must be empty.
### Example
@@ -649,6 +665,8 @@ void (empty response body)
# **delete_catalog_role**
> delete_catalog_role(catalog_name, catalog_role_name)
+
+
Delete an existing role from the catalog. All associated grants will also be
deleted
### Example
@@ -722,6 +740,8 @@ void (empty response body)
# **delete_principal**
> delete_principal(principal_name)
+
+
Remove a principal from polaris
### Example
@@ -793,6 +813,8 @@ void (empty response body)
# **delete_principal_role**
> delete_principal_role(principal_role_name)
+
+
Remove a principal role from polaris
### Example
@@ -864,6 +886,8 @@ void (empty response body)
# **get_catalog**
> Catalog get_catalog(catalog_name)
+
+
Get the details of a catalog
### Example
@@ -938,6 +962,8 @@ Name | Type | Description | Notes
# **get_catalog_role**
> CatalogRole get_catalog_role(catalog_name, catalog_role_name)
+
+
Get the details of an existing role
### Example
@@ -1014,6 +1040,8 @@ Name | Type | Description | Notes
# **get_principal**
> Principal get_principal(principal_name)
+
+
Get the principal details
### Example
@@ -1088,6 +1116,8 @@ Name | Type | Description | Notes
# **get_principal_role**
> PrincipalRole get_principal_role(principal_role_name)
+
+
Get the principal role details
### Example
@@ -1162,6 +1192,8 @@ Name | Type | Description | Notes
# **list_assignee_principal_roles_for_catalog_role**
> PrincipalRoles list_assignee_principal_roles_for_catalog_role(catalog_name,
> catalog_role_name)
+
+
List the PrincipalRoles to which the target catalog role has been assigned
### Example
@@ -1238,6 +1270,8 @@ Name | Type | Description | Notes
# **list_assignee_principals_for_principal_role**
> Principals list_assignee_principals_for_principal_role(principal_role_name)
+
+
List the Principals to whom the target principal role has been assigned
### Example
@@ -1312,6 +1346,8 @@ Name | Type | Description | Notes
# **list_catalog_roles**
> CatalogRoles list_catalog_roles(catalog_name)
+
+
List existing roles in the catalog
### Example
@@ -1384,6 +1420,8 @@ Name | Type | Description | Notes
# **list_catalog_roles_for_principal_role**
> CatalogRoles list_catalog_roles_for_principal_role(principal_role_name,
> catalog_name)
+
+
Get the catalog roles mapped to the principal role
### Example
@@ -1460,6 +1498,8 @@ Name | Type | Description | Notes
# **list_catalogs**
> Catalogs list_catalogs()
+
+
List all catalogs in this polaris service
### Example
@@ -1529,6 +1569,8 @@ This endpoint does not need any parameter.
# **list_grants_for_catalog_role**
> GrantResources list_grants_for_catalog_role(catalog_name, catalog_role_name)
+
+
List the grants the catalog role holds
### Example
@@ -1603,6 +1645,8 @@ Name | Type | Description | Notes
# **list_principal_roles**
> PrincipalRoles list_principal_roles()
+
+
List the principal roles
### Example
@@ -1673,6 +1717,8 @@ This endpoint does not need any parameter.
# **list_principal_roles_assigned**
> PrincipalRoles list_principal_roles_assigned(principal_name)
+
+
List the roles assigned to the principal
### Example
@@ -1747,6 +1793,8 @@ Name | Type | Description | Notes
# **list_principals**
> Principals list_principals()
+
+
List the principals for the current catalog
### Example
@@ -1817,6 +1865,8 @@ This endpoint does not need any parameter.
# **revoke_catalog_role_from_principal_role**
> revoke_catalog_role_from_principal_role(principal_role_name, catalog_name,
> catalog_role_name)
+
+
Remove a catalog role from a principal role
### Example
@@ -1892,6 +1942,8 @@ void (empty response body)
# **revoke_grant_from_catalog_role**
> revoke_grant_from_catalog_role(catalog_name, catalog_role_name,
> cascade=cascade, revoke_grant_request=revoke_grant_request)
+
+
Delete a specific grant from the role. This may be a subset or a superset of
the grants the role has. In case of a subset, the role will retain the grants
not specified. If the `cascade` parameter is true, grant revocation will have a
cascading effect - that is, if a principal has specific grants on a
subresource, and grants are revoked on a parent resource, the grants present on
the subresource will be revoked as well. By default, this behavior is disabled
and grant revocation only affe [...]
### Example
@@ -1970,6 +2022,8 @@ void (empty response body)
# **revoke_principal_role**
> revoke_principal_role(principal_name, principal_role_name)
+
+
Remove a role from a catalog principal
### Example
@@ -2043,6 +2097,8 @@ void (empty response body)
# **rotate_credentials**
> PrincipalWithCredentials rotate_credentials(principal_name)
+
+
Rotate a principal's credentials. The new credentials will be returned in the
response. This is the only API, aside from createPrincipal, that returns the
user's credentials. This API is *not* idempotent.
### Example
@@ -2117,6 +2173,8 @@ Name | Type | Description | Notes
# **update_catalog**
> Catalog update_catalog(catalog_name, update_catalog_request)
+
+
Update an existing catalog
### Example
@@ -2195,6 +2253,8 @@ Name | Type | Description | Notes
# **update_catalog_role**
> CatalogRole update_catalog_role(catalog_name, catalog_role_name,
> update_catalog_role_request=update_catalog_role_request)
+
+
Update an existing role in the catalog
### Example
@@ -2275,6 +2335,8 @@ Name | Type | Description | Notes
# **update_principal**
> Principal update_principal(principal_name, update_principal_request)
+
+
Update an existing principal
### Example
@@ -2353,6 +2415,8 @@ Name | Type | Description | Notes
# **update_principal_role**
> PrincipalRole update_principal_role(principal_role_name,
> update_principal_role_request)
+
+
Update an existing principalRole
### Example
diff --git a/client/python/docs/PolicyAPI.md b/client/python/docs/PolicyAPI.md
index 2612bc592..92684a6c1 100644
--- a/client/python/docs/PolicyAPI.md
+++ b/client/python/docs/PolicyAPI.md
@@ -39,27 +39,7 @@ Method | HTTP request | Description
Create a mapping between a policy and a resource entity
-Create a mapping between a policy and a resource entity
-
-Policy can be attached to different levels:
-1. **Table-like level:** Policies specific to individual tables or views.
-2. **Namespace level:** Policies applies to a namespace.
-3. **Catalog level:** Policies that applies to a catalog
-
-The ability to attach a policy to a specific entity type is governed by the
PolicyValidator. A policy can only be attached if the resource entity is a
valid target for the specified policy type.
-
-In addition to the validation rules enforced by the PolicyValidator, there are
additional constraints on policy attachment:
-1. For inheritable policies, only one policy of the same type can be attached
to a given resource entity.
-2. For non-inheritable policies, multiple policies of the same type can be
attached to the same resource entity without restriction.
-
-For inheritable policies, the inheritance override rule is:
-1. Table-like level policies override namespace and catalog policies.
-2. Namespace-level policies override upper level namespace or catalog policies.
-
-Additional parameters can be provided in `parameters` when creating a mapping
to define specific behavior or constraints.
-
-If the policy is already attached to the target entity, the existing mapping
record will be updated with the new set of parameters, replacing the previous
ones.
-
+Create a mapping between a policy and a resource entity Policy can be
attached to different levels: 1. **Table-like level:** Policies specific to
individual tables or views. 2. **Namespace level:** Policies applies to a
namespace. 3. **Catalog level:** Policies that applies to a catalog The
ability to attach a policy to a specific entity type is governed by the
PolicyValidator. A policy can only be attached if the resource entity is a
valid target for the specified policy type. In add [...]
### Example
@@ -151,22 +131,7 @@ void (empty response body)
Create a policy in the given namespace
-Creates a policy within the specified namespace.
-
-A policy defines a set of rules governing actions on specified resources under
predefined conditions.
-In Apache Polaris, policies are created, stored, and later referenced by
external engines to enforce access controls on associated resources.
-
-User provides the following inputs when creating a policy
-- `name` (REQUIRED): The name of the policy.
-- `type` (REQUIRED): The type of the policy.
- - **Predefined Policies:** policies have a `system.*` prefix in their type,
such as `system.data_compaction`
-- `description` (OPTIONAL): Provides details about the policy's purpose and
functionality
-- `content` (OPTIONAL): Defines the rules that control actions and access
conditions on resources. The format can be JSON, SQL, or any other format.
-
-The content field in the request body is validated using the policy's
corresponding validator. The policy is created only if the content passes
validation.
-
-Upon successful creation, the new policy's version will be 0.
-
+Creates a policy within the specified namespace. A policy defines a set of
rules governing actions on specified resources under predefined conditions. In
Apache Polaris, policies are created, stored, and later referenced by external
engines to enforce access controls on associated resources. User provides the
following inputs when creating a policy - `name` (REQUIRED): The name of the
policy. - `type` (REQUIRED): The type of the policy. - **Predefined
Policies:** policies have a `sys [...]
### Example
@@ -259,10 +224,7 @@ Name | Type | Description | Notes
Remove a mapping between a policy and a target entity
-Remove a mapping between a policy and a target entity
-
-A target entity can be a catalog, namespace, table or view.
-
+Remove a mapping between a policy and a target entity A target entity can be
a catalog, namespace, table or view.
### Example
@@ -353,10 +315,7 @@ void (empty response body)
Drop a policy from the catalog
-Remove a policy from the catalog.
-
-A policy can only be dropped if it is not attached to any resource entity. To
remove the policy along with all its attachments, set detach-all to true.
-
+Remove a policy from the catalog. A policy can only be dropped if it is not
attached to any resource entity. To remove the policy along with all its
attachments, set detach-all to true.
### Example
@@ -446,24 +405,7 @@ void (empty response body)
Get Applicable policies for catalog, namespace, table, or views
-Retrieves all applicable policies for a specified entity, including inherited
policies from parent entities. An entity can be a table/view, namespace, or
catalog. The required parameters depend on the entity type:
-
-- Table/View:
- - The `namespace` parameter is required to specify the entity's namespace.
- - The `target-name` parameter is required to specify the entity name.
-- Namespace:
- - The `namespace` parameter is required to specify the identifier.
- - The `target-name` parameter should not be set.
-- Catalog:
- - Neither `namespace` nor `target-name` should be set.
-
-An optional policyType parameter filters results to return only policies of
the specified type.
-
-This API evaluates the entity's hierarchy and applies inheritable policies
from parent entities. The inheritance follows the following override rule:
-
-1. Table-like level policies override namespace and catalog policies.
-2. Namespace-level policies override upper level namespace or catalog policies.
-
+Retrieves all applicable policies for a specified entity, including inherited
policies from parent entities. An entity can be a table/view, namespace, or
catalog. The required parameters depend on the entity type: - Table/View: -
The `namespace` parameter is required to specify the entity's namespace. -
The `target-name` parameter is required to specify the entity name. -
Namespace: - The `namespace` parameter is required to specify the identifier.
- The `target-name` parameter [...]
### Example
@@ -655,10 +597,7 @@ Name | Type | Description | Notes
Load a policy
-Load a policy from the catalog
-
-The response contains the policy's metadata and content. For more details,
refer to the definition of the `Policy` model.
-
+Load a policy from the catalog The response contains the policy's metadata
and content. For more details, refer to the definition of the `Policy` model.
### Example
@@ -749,13 +688,7 @@ Name | Type | Description | Notes
Update a policy
-Update a policy
-
-A policy's description and content can be updated. The new content is
validated against the policy's corresponding validator.
-Upon a successful update, the policy's version is incremented by 1.
-
-The update will only succeed if the current version matches the one in the
catalog.
-
+Update a policy A policy's description and content can be updated. The new
content is validated against the policy's corresponding validator. Upon a
successful update, the policy's version is incremented by 1. The update will
only succeed if the current version matches the one in the catalog.
### Example
diff --git a/client/python/polaris/catalog/configuration.py
b/client/python/polaris/catalog/configuration.py
index 69d0a877c..6259fba54 100644
--- a/client/python/polaris/catalog/configuration.py
+++ b/client/python/polaris/catalog/configuration.py
@@ -37,7 +37,7 @@ import logging
from logging import FileHandler
import multiprocessing
import sys
-from typing import Any, ClassVar, Dict, List, Literal, Optional, TypedDict,
Union
+from typing import Any, ClassVar, Dict, List, Literal, Optional, TypedDict
from typing_extensions import NotRequired, Self
import urllib3
@@ -181,8 +181,6 @@ class Configuration:
:param ssl_ca_cert: str - the path to a file of concatenated CA
certificates
in PEM format.
:param retries: Number of retries for API requests.
- :param ca_cert_data: verify the peer using concatenated CA certificate data
- in PEM (str) or DER (bytes) format.
:Example:
"""
@@ -197,14 +195,13 @@ class Configuration:
username: Optional[str]=None,
password: Optional[str]=None,
access_token: Optional[str]=None,
- server_index: Optional[int]=None,
+ server_index: Optional[int]=None,
server_variables: Optional[ServerVariablesT]=None,
server_operation_index: Optional[Dict[int, int]]=None,
server_operation_variables: Optional[Dict[int, ServerVariablesT]]=None,
ignore_operation_servers: bool=False,
ssl_ca_cert: Optional[str]=None,
retries: Optional[int] = None,
- ca_cert_data: Optional[Union[str, bytes]] = None,
*,
debug: Optional[bool] = None,
) -> None:
@@ -282,10 +279,6 @@ class Configuration:
self.ssl_ca_cert = ssl_ca_cert
"""Set this to customize the certificate file to verify the peer.
"""
- self.ca_cert_data = ca_cert_data
- """Set this to verify the peer using PEM (str) or DER (bytes)
- certificate data.
- """
self.cert_file = None
"""client certificate file
"""
diff --git a/client/python/polaris/catalog/rest.py
b/client/python/polaris/catalog/rest.py
index b48ee180c..d5fddb043 100644
--- a/client/python/polaris/catalog/rest.py
+++ b/client/python/polaris/catalog/rest.py
@@ -95,7 +95,6 @@ class RESTClientObject:
"ca_certs": configuration.ssl_ca_cert,
"cert_file": configuration.cert_file,
"key_file": configuration.key_file,
- "ca_cert_data": configuration.ca_cert_data,
}
if configuration.assert_hostname is not None:
pool_args['assert_hostname'] = (
diff --git a/client/python/polaris/management/configuration.py
b/client/python/polaris/management/configuration.py
index a95beaf65..714dac242 100644
--- a/client/python/polaris/management/configuration.py
+++ b/client/python/polaris/management/configuration.py
@@ -37,7 +37,7 @@ import logging
from logging import FileHandler
import multiprocessing
import sys
-from typing import Any, ClassVar, Dict, List, Literal, Optional, TypedDict,
Union
+from typing import Any, ClassVar, Dict, List, Literal, Optional, TypedDict
from typing_extensions import NotRequired, Self
import urllib3
@@ -180,8 +180,6 @@ class Configuration:
:param ssl_ca_cert: str - the path to a file of concatenated CA
certificates
in PEM format.
:param retries: Number of retries for API requests.
- :param ca_cert_data: verify the peer using concatenated CA certificate data
- in PEM (str) or DER (bytes) format.
:Example:
"""
@@ -196,14 +194,13 @@ class Configuration:
username: Optional[str]=None,
password: Optional[str]=None,
access_token: Optional[str]=None,
- server_index: Optional[int]=None,
+ server_index: Optional[int]=None,
server_variables: Optional[ServerVariablesT]=None,
server_operation_index: Optional[Dict[int, int]]=None,
server_operation_variables: Optional[Dict[int, ServerVariablesT]]=None,
ignore_operation_servers: bool=False,
ssl_ca_cert: Optional[str]=None,
retries: Optional[int] = None,
- ca_cert_data: Optional[Union[str, bytes]] = None,
*,
debug: Optional[bool] = None,
) -> None:
@@ -281,10 +278,6 @@ class Configuration:
self.ssl_ca_cert = ssl_ca_cert
"""Set this to customize the certificate file to verify the peer.
"""
- self.ca_cert_data = ca_cert_data
- """Set this to verify the peer using PEM (str) or DER (bytes)
- certificate data.
- """
self.cert_file = None
"""client certificate file
"""
diff --git a/client/python/polaris/management/rest.py
b/client/python/polaris/management/rest.py
index 1253e20e4..2eae77512 100644
--- a/client/python/polaris/management/rest.py
+++ b/client/python/polaris/management/rest.py
@@ -95,7 +95,6 @@ class RESTClientObject:
"ca_certs": configuration.ssl_ca_cert,
"cert_file": configuration.cert_file,
"key_file": configuration.key_file,
- "ca_cert_data": configuration.ca_cert_data,
}
if configuration.assert_hostname is not None:
pool_args['assert_hostname'] = (
diff --git a/client/templates/regenerate.sh b/client/templates/regenerate.sh
index 13e2318cd..8179c71a0 100755
--- a/client/templates/regenerate.sh
+++ b/client/templates/regenerate.sh
@@ -60,7 +60,7 @@ echo "Regenerating python from the spec"
# TODO skip-validate-spec is needed because the upstream Iceberg spec seems
invalid. e.g.:
# [main] ERROR o.o.codegen.DefaultCodegen - Required var sort-order-id not
in properties
-OPEN_API_CLI_VERSION="v7.12.0"
+OPEN_API_CLI_VERSION="v7.11.0"
docker run --rm \
-v "${SCRIPT_DIR}/../..:/local" \
@@ -133,6 +133,7 @@ EXCLUDE_PATHS=(
"./requirements.txt"
"./test-requirements.txt"
"./setup.py"
+ "./.DS_Store"
)
EXCLUDE_EXTENSIONS=(
