You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
author Mend Renovate <bot@renovateapp.com> 1749165686 +0200
committer Rizzo Cascio, Fabio <fabio.rizzocascio@jpmorgan.com> 1749485275 +0100
# This is a combination of 18 commits.
# This is the 1st commit message:
Mutable objects used for immutable values #772: fixed tests and formatting and updated from main
Copy file name to clipboardExpand all lines: client/python/docs/CatalogAPI.md
+6-30Lines changed: 6 additions & 30 deletions
Original file line number
Diff line number
Diff line change
@@ -238,11 +238,7 @@ Name | Type | Description | Notes
238
238
239
239
Create a table in the given namespace
240
240
241
-
Create a table or start a create transaction, like atomic CTAS.
242
-
243
-
If `stage-create` is false, the table is created immediately.
244
-
245
-
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 set the initial table state.
241
+
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 set the initial table state.
246
242
247
243
### Example
248
244
@@ -697,7 +693,7 @@ void (empty response body)
697
693
698
694
List namespaces, optionally providing a parent namespace to list underneath
699
695
700
-
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-level namespaces should be listed.
696
+
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-level namespaces should be listed.
701
697
702
698
### Example
703
699
@@ -1161,13 +1157,7 @@ Name | Type | Description | Notes
1161
1157
1162
1158
Load a table from the catalog
1163
1159
1164
-
Load a table from the catalog.
1165
-
1166
-
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.
1167
-
1168
-
The response also contains the table's full metadata, matching the table metadata JSON file.
1169
-
1170
-
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>".
1160
+
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>\".
1171
1161
1172
1162
### Example
1173
1163
@@ -1266,13 +1256,7 @@ Name | Type | Description | Notes
1266
1256
1267
1257
Load a view from the catalog
1268
1258
1269
-
Load a view from the catalog.
1270
-
1271
-
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.
1272
-
1273
-
The response also contains the view's full metadata, matching the view metadata JSON file.
1274
-
1275
-
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>".
1259
+
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>\".
1276
1260
1277
1261
### Example
1278
1262
@@ -2094,9 +2078,7 @@ void (empty response body)
2094
2078
2095
2079
Set or remove properties on a namespace
2096
2080
2097
-
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.
2098
-
Properties that are not in the request are not modified or removed by this call.
2099
-
Server implementations are not required to support namespace properties.
2081
+
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.
2100
2082
2101
2083
### Example
2102
2084
@@ -2191,13 +2173,7 @@ Name | Type | Description | Notes
2191
2173
2192
2174
Commit updates to a table
2193
2175
2194
-
Commit updates to a table.
2195
-
2196
-
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.
2197
-
2198
-
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.
2199
-
2200
-
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.
2176
+
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.
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.
36
-
- defaults - properties that should be used as default configuration; applied before client configuration
37
-
- overrides - properties that should be used to override client configuration; applied after defaults and client configuration
38
-
39
-
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.
40
-
41
-
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.
42
-
43
-
Common catalog configuration settings are documented at https://iceberg.apache.org/docs/latest/configuration/#catalog-properties
44
-
45
-
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:
46
-
- GET /v1/{prefix}/namespaces
47
-
- POST /v1/{prefix}/namespaces
48
-
- GET /v1/{prefix}/namespaces/{namespace}
49
-
- DELETE /v1/{prefix}/namespaces/{namespace}
50
-
- POST /v1/{prefix}/namespaces/{namespace}/properties
51
-
- GET /v1/{prefix}/namespaces/{namespace}/tables
52
-
- POST /v1/{prefix}/namespaces/{namespace}/tables
53
-
- GET /v1/{prefix}/namespaces/{namespace}/tables/{table}
54
-
- POST /v1/{prefix}/namespaces/{namespace}/tables/{table}
- POST /v1/{prefix}/namespaces/{namespace}/register
57
-
- POST /v1/{prefix}/namespaces/{namespace}/tables/{table}/metrics
58
-
- POST /v1/{prefix}/tables/rename
59
-
- POST /v1/{prefix}/transactions/commit
35
+
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
0 commit comments