hotdata 0.12.0__tar.gz → 0.13.0__tar.gz

{hotdata-0.12.0 → hotdata-0.13.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: hotdata
-Version: 0.12.0
+Version: 0.13.0
 Summary: Hotdata API
 Author-email: Hotdata <developers@hotdata.dev>
 License: MIT

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/__init__.py

@@ -146,6 +146,7 @@ __all__ = [
     "SavedQueryVersionInfo",
     "SubmitJobResponse",
     "TableInfo",
+    "TableLayout",
     "TablePartitionKey",
     "TableProfileResponse",
     "TableSortKey",
@@ -290,6 +291,7 @@ from hotdata.models.saved_query_summary import SavedQuerySummary as SavedQuerySu
 from hotdata.models.saved_query_version_info import SavedQueryVersionInfo as SavedQueryVersionInfo
 from hotdata.models.submit_job_response import SubmitJobResponse as SubmitJobResponse
 from hotdata.models.table_info import TableInfo as TableInfo
+from hotdata.models.table_layout import TableLayout as TableLayout
 from hotdata.models.table_partition_key import TablePartitionKey as TablePartitionKey
 from hotdata.models.table_profile_response import TableProfileResponse as TableProfileResponse
 from hotdata.models.table_sort_key import TableSortKey as TableSortKey

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/api/connections_api.py

@@ -2339,7 +2339,7 @@ class ConnectionsApi:
     ) -> LoadManagedTableResponse:
         """Load managed table from inline data, upload, or query result
 
-        Publish data as the new contents of a managed table from one of three sources — provide exactly one. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected from the upload's `Content-Type` and file contents, or set explicitly via the `format` field. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires; a result can be loaded into any number of tables. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied and accepts five values: `replace` makes the uploaded rows the table's entire contents, `append` inserts them on top of the existing data, and `delete`, `update`, and `upsert` match rows by key — removing, replacing, or inserting-or-replacing the matched rows respectively. The three key-matching modes need a key: the one the table was created with, or one given in `key` on the request. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously.
+        Publish data as the new contents of a managed table from one of three sources — provide exactly one. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected from the upload's `Content-Type` and file contents, or set explicitly via the `format` field. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires; a result can be loaded into any number of tables. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied and accepts five values: `replace` makes the uploaded rows the table's entire contents, `append` inserts them on top of the existing data, and `delete`, `update`, and `upsert` match rows by key — removing, replacing, or inserting-or-replacing the matched rows respectively. The three key-matching modes need a key: the one the table was created with, or one given in `key` on the request. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously. While background maintenance holds the table, a load waits for it to finish, for up to 60 seconds, before it starts, in every mode; with `async`, the 202 can arrive only after that wait. A load refused because another write to the table is running gets 409 with the error code `RESOURCE_LOCKED` and a `Retry-After` header.
 
         :param connection_id: Connection ID (required)
         :type connection_id: str
@@ -2389,6 +2389,7 @@ class ConnectionsApi:
             '404': "ApiErrorResponse",
             '409': "ApiErrorResponse",
             '413': "ApiErrorResponse",
+            '503': "ApiErrorResponse",
         }
         response_data = self.api_client.call_api(
             *_param,
@@ -2423,7 +2424,7 @@ class ConnectionsApi:
     ) -> ApiResponse[LoadManagedTableResponse]:
         """Load managed table from inline data, upload, or query result
 
-        Publish data as the new contents of a managed table from one of three sources — provide exactly one. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected from the upload's `Content-Type` and file contents, or set explicitly via the `format` field. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires; a result can be loaded into any number of tables. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied and accepts five values: `replace` makes the uploaded rows the table's entire contents, `append` inserts them on top of the existing data, and `delete`, `update`, and `upsert` match rows by key — removing, replacing, or inserting-or-replacing the matched rows respectively. The three key-matching modes need a key: the one the table was created with, or one given in `key` on the request. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously.
+        Publish data as the new contents of a managed table from one of three sources — provide exactly one. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected from the upload's `Content-Type` and file contents, or set explicitly via the `format` field. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires; a result can be loaded into any number of tables. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied and accepts five values: `replace` makes the uploaded rows the table's entire contents, `append` inserts them on top of the existing data, and `delete`, `update`, and `upsert` match rows by key — removing, replacing, or inserting-or-replacing the matched rows respectively. The three key-matching modes need a key: the one the table was created with, or one given in `key` on the request. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously. While background maintenance holds the table, a load waits for it to finish, for up to 60 seconds, before it starts, in every mode; with `async`, the 202 can arrive only after that wait. A load refused because another write to the table is running gets 409 with the error code `RESOURCE_LOCKED` and a `Retry-After` header.
 
         :param connection_id: Connection ID (required)
         :type connection_id: str
@@ -2473,6 +2474,7 @@ class ConnectionsApi:
             '404': "ApiErrorResponse",
             '409': "ApiErrorResponse",
             '413': "ApiErrorResponse",
+            '503': "ApiErrorResponse",
         }
         response_data = self.api_client.call_api(
             *_param,
@@ -2507,7 +2509,7 @@ class ConnectionsApi:
     ) -> RESTResponseType:
         """Load managed table from inline data, upload, or query result
 
-        Publish data as the new contents of a managed table from one of three sources — provide exactly one. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected from the upload's `Content-Type` and file contents, or set explicitly via the `format` field. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires; a result can be loaded into any number of tables. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied and accepts five values: `replace` makes the uploaded rows the table's entire contents, `append` inserts them on top of the existing data, and `delete`, `update`, and `upsert` match rows by key — removing, replacing, or inserting-or-replacing the matched rows respectively. The three key-matching modes need a key: the one the table was created with, or one given in `key` on the request. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously.
+        Publish data as the new contents of a managed table from one of three sources — provide exactly one. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected from the upload's `Content-Type` and file contents, or set explicitly via the `format` field. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires; a result can be loaded into any number of tables. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied and accepts five values: `replace` makes the uploaded rows the table's entire contents, `append` inserts them on top of the existing data, and `delete`, `update`, and `upsert` match rows by key — removing, replacing, or inserting-or-replacing the matched rows respectively. The three key-matching modes need a key: the one the table was created with, or one given in `key` on the request. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously. While background maintenance holds the table, a load waits for it to finish, for up to 60 seconds, before it starts, in every mode; with `async`, the 202 can arrive only after that wait. A load refused because another write to the table is running gets 409 with the error code `RESOURCE_LOCKED` and a `Retry-After` header.
 
         :param connection_id: Connection ID (required)
         :type connection_id: str
@@ -2557,6 +2559,7 @@ class ConnectionsApi:
             '404': "ApiErrorResponse",
             '409': "ApiErrorResponse",
             '413': "ApiErrorResponse",
+            '503': "ApiErrorResponse",
         }
         response_data = self.api_client.call_api(
             *_param,

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/api/databases_api.py

@@ -4082,7 +4082,7 @@ class DatabasesApi:
     ) -> LoadManagedTableResponse:
         """Load database table from inline data, upload, or query result
 
-        Publish data as the new contents of a table on the database's default catalog, from one of three sources — provide exactly one. The database-scoped equivalent of the connection-scoped managed-table load — addressed by `database_id`, so no `default_connection_id` is needed. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected or set via `format`. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied: `replace` overwrites the table's contents, `append` inserts the new rows on top of the existing data. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously.
+        Publish data as the new contents of a table on the database's default catalog, from one of three sources — provide exactly one. The database-scoped equivalent of the connection-scoped managed-table load — addressed by `database_id`, so no `default_connection_id` is needed. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected or set via `format`. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied: `replace` overwrites the table's contents, `append` inserts the new rows on top of the existing data. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously. While background maintenance holds the table, a load waits for it to finish, for up to 60 seconds, before it starts, in every mode; with `async`, the 202 can arrive only after that wait. A load refused because another write to the table is running gets 409 with the error code `RESOURCE_LOCKED` and a `Retry-After` header.
 
         :param database_id: Database ID (required)
         :type database_id: str
@@ -4132,6 +4132,7 @@ class DatabasesApi:
             '404': "ApiErrorResponse",
             '409': "ApiErrorResponse",
             '413': "ApiErrorResponse",
+            '503': "ApiErrorResponse",
         }
         response_data = self.api_client.call_api(
             *_param,
@@ -4166,7 +4167,7 @@ class DatabasesApi:
     ) -> ApiResponse[LoadManagedTableResponse]:
         """Load database table from inline data, upload, or query result
 
-        Publish data as the new contents of a table on the database's default catalog, from one of three sources — provide exactly one. The database-scoped equivalent of the connection-scoped managed-table load — addressed by `database_id`, so no `default_connection_id` is needed. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected or set via `format`. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied: `replace` overwrites the table's contents, `append` inserts the new rows on top of the existing data. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously.
+        Publish data as the new contents of a table on the database's default catalog, from one of three sources — provide exactly one. The database-scoped equivalent of the connection-scoped managed-table load — addressed by `database_id`, so no `default_connection_id` is needed. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected or set via `format`. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied: `replace` overwrites the table's contents, `append` inserts the new rows on top of the existing data. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously. While background maintenance holds the table, a load waits for it to finish, for up to 60 seconds, before it starts, in every mode; with `async`, the 202 can arrive only after that wait. A load refused because another write to the table is running gets 409 with the error code `RESOURCE_LOCKED` and a `Retry-After` header.
 
         :param database_id: Database ID (required)
         :type database_id: str
@@ -4216,6 +4217,7 @@ class DatabasesApi:
             '404': "ApiErrorResponse",
             '409': "ApiErrorResponse",
             '413': "ApiErrorResponse",
+            '503': "ApiErrorResponse",
         }
         response_data = self.api_client.call_api(
             *_param,
@@ -4250,7 +4252,7 @@ class DatabasesApi:
     ) -> RESTResponseType:
         """Load database table from inline data, upload, or query result
 
-        Publish data as the new contents of a table on the database's default catalog, from one of three sources — provide exactly one. The database-scoped equivalent of the connection-scoped managed-table load — addressed by `database_id`, so no `default_connection_id` is needed. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected or set via `format`. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied: `replace` overwrites the table's contents, `append` inserts the new rows on top of the existing data. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously.
+        Publish data as the new contents of a table on the database's default catalog, from one of three sources — provide exactly one. The database-scoped equivalent of the connection-scoped managed-table load — addressed by `database_id`, so no `default_connection_id` is needed. With `data`, CSV text is sent inline in this request, up to 2 MiB; column types are detected from the data unless `columns` declares them, and a larger payload is rejected with 413 and the error code `INLINE_DATA_TOO_LARGE`, at which point the data should be uploaded and loaded by `upload_id` instead. With `upload_id`, a previously-uploaded file is published: CSV, JSON, and Parquet are supported; the format is auto-detected or set via `format`. With `result_id`, a persisted query result is copied into the table, so the table keeps its data even after the result expires. If the target table (or its schema) has not been declared yet, it is created automatically as part of the load — declaring tables up front is optional. `mode` selects how the data is applied: `replace` overwrites the table's contents, `append` inserts the new rows on top of the existing data. Concurrent loads against the same upload return 409. For an upload or inline data, set `async` to run the load in the background and get back a job ID to poll; add `async_after_ms` to wait briefly for it to finish before falling back to a job ID. A `result_id` load runs synchronously. While background maintenance holds the table, a load waits for it to finish, for up to 60 seconds, before it starts, in every mode; with `async`, the 202 can arrive only after that wait. A load refused because another write to the table is running gets 409 with the error code `RESOURCE_LOCKED` and a `Retry-After` header.
 
         :param database_id: Database ID (required)
         :type database_id: str
@@ -4300,6 +4302,7 @@ class DatabasesApi:
             '404': "ApiErrorResponse",
             '409': "ApiErrorResponse",
             '413': "ApiErrorResponse",
+            '503': "ApiErrorResponse",
         }
         response_data = self.api_client.call_api(
             *_param,

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/api/query_api.py

@@ -60,7 +60,7 @@ class QueryApi:
     ) -> QueryResponse:
         """Execute SQL query
 
-        Execute a SQL query scoped to a database. A database is the only window into catalogs: the query sees only that database's auto `default` catalog plus any catalogs explicitly attached to it. Select the database with EITHER the `X-Database-Id` header OR the `database_id` body field (exactly one must be given; if both are sent and disagree, that's a 400). Use standard Postgres-compatible SQL; reference the default catalog as `default.<schema>.<table>` (or just `<schema>.<table>` / `<table>`) and attached catalogs by their alias. Results are returned inline and a `result_id` is provided for later retrieval via the Results API.  Set `async: true` to execute asynchronously — returns a query run ID for polling. Optionally set `async_after_ms` to attempt synchronous execution first, falling back to async if the query exceeds the timeout.  To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.
+        Execute a SQL query scoped to a database. A database is the only window into catalogs: the query sees only that database's auto `default` catalog plus any catalogs explicitly attached to it. Select the database with EITHER the `X-Database-Id` header OR the `database_id` body field (exactly one must be given; if both are sent and disagree, that's a 400). Use standard Postgres-compatible SQL; reference the default catalog as `default.<schema>.<table>` (or just `<schema>.<table>` / `<table>`) and attached catalogs by their alias. Results are returned inline and a `result_id` is provided for later retrieval via the Results API.  Set `async: true` to execute asynchronously — returns a query run ID for polling. Optionally set `async_after_ms` to attempt synchronous execution first, falling back to async if the query exceeds the timeout.  To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.  The endpoint also runs write statements: `INSERT INTO … VALUES … / SELECT …` (append only), `UPDATE … SET … [WHERE …]`, `DELETE FROM … [WHERE …]`, `CREATE TABLE`, `CREATE TABLE … AS SELECT …` and `DROP TABLE`. A write runs once, inline, and answers with a one-row result holding a single `rows_affected` column. Writes need an API key holding both the `read` and `write` permissions, may only target the database's own `default` catalog (attached catalogs stay read-only), and are never run from a saved query. A `DELETE` reports the number of rows its `WHERE` matched and deleted; `DELETE … LIMIT`, `USING` and `RETURNING` are refused. An `UPDATE` reports the number of rows its `WHERE` matched. Each `SET` value is computed from the row as it was before the statement, so `SET a = b, b = a` swaps two values. An `UPDATE` cannot use a table alias, `FROM`, `RETURNING`, `LIMIT` or `ORDER BY`, cannot set one column twice, and cannot set a column that a vector index generates; that column is computed again from its source text. On a table that declares `constant_per_key`, an `UPDATE` cannot set a key column or a `constant_per_key` column. Every other mutation (`ALTER`, views, `COPY`, transactions, `EXPLAIN` of a write) is refused.
 
         :param query_request: (required)
         :type query_request: QueryRequest
@@ -137,7 +137,7 @@ class QueryApi:
     ) -> ApiResponse[QueryResponse]:
         """Execute SQL query
 
-        Execute a SQL query scoped to a database. A database is the only window into catalogs: the query sees only that database's auto `default` catalog plus any catalogs explicitly attached to it. Select the database with EITHER the `X-Database-Id` header OR the `database_id` body field (exactly one must be given; if both are sent and disagree, that's a 400). Use standard Postgres-compatible SQL; reference the default catalog as `default.<schema>.<table>` (or just `<schema>.<table>` / `<table>`) and attached catalogs by their alias. Results are returned inline and a `result_id` is provided for later retrieval via the Results API.  Set `async: true` to execute asynchronously — returns a query run ID for polling. Optionally set `async_after_ms` to attempt synchronous execution first, falling back to async if the query exceeds the timeout.  To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.
+        Execute a SQL query scoped to a database. A database is the only window into catalogs: the query sees only that database's auto `default` catalog plus any catalogs explicitly attached to it. Select the database with EITHER the `X-Database-Id` header OR the `database_id` body field (exactly one must be given; if both are sent and disagree, that's a 400). Use standard Postgres-compatible SQL; reference the default catalog as `default.<schema>.<table>` (or just `<schema>.<table>` / `<table>`) and attached catalogs by their alias. Results are returned inline and a `result_id` is provided for later retrieval via the Results API.  Set `async: true` to execute asynchronously — returns a query run ID for polling. Optionally set `async_after_ms` to attempt synchronous execution first, falling back to async if the query exceeds the timeout.  To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.  The endpoint also runs write statements: `INSERT INTO … VALUES … / SELECT …` (append only), `UPDATE … SET … [WHERE …]`, `DELETE FROM … [WHERE …]`, `CREATE TABLE`, `CREATE TABLE … AS SELECT …` and `DROP TABLE`. A write runs once, inline, and answers with a one-row result holding a single `rows_affected` column. Writes need an API key holding both the `read` and `write` permissions, may only target the database's own `default` catalog (attached catalogs stay read-only), and are never run from a saved query. A `DELETE` reports the number of rows its `WHERE` matched and deleted; `DELETE … LIMIT`, `USING` and `RETURNING` are refused. An `UPDATE` reports the number of rows its `WHERE` matched. Each `SET` value is computed from the row as it was before the statement, so `SET a = b, b = a` swaps two values. An `UPDATE` cannot use a table alias, `FROM`, `RETURNING`, `LIMIT` or `ORDER BY`, cannot set one column twice, and cannot set a column that a vector index generates; that column is computed again from its source text. On a table that declares `constant_per_key`, an `UPDATE` cannot set a key column or a `constant_per_key` column. Every other mutation (`ALTER`, views, `COPY`, transactions, `EXPLAIN` of a write) is refused.
 
         :param query_request: (required)
         :type query_request: QueryRequest
@@ -214,7 +214,7 @@ class QueryApi:
     ) -> RESTResponseType:
         """Execute SQL query
 
-        Execute a SQL query scoped to a database. A database is the only window into catalogs: the query sees only that database's auto `default` catalog plus any catalogs explicitly attached to it. Select the database with EITHER the `X-Database-Id` header OR the `database_id` body field (exactly one must be given; if both are sent and disagree, that's a 400). Use standard Postgres-compatible SQL; reference the default catalog as `default.<schema>.<table>` (or just `<schema>.<table>` / `<table>`) and attached catalogs by their alias. Results are returned inline and a `result_id` is provided for later retrieval via the Results API.  Set `async: true` to execute asynchronously — returns a query run ID for polling. Optionally set `async_after_ms` to attempt synchronous execution first, falling back to async if the query exceeds the timeout.  To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.
+        Execute a SQL query scoped to a database. A database is the only window into catalogs: the query sees only that database's auto `default` catalog plus any catalogs explicitly attached to it. Select the database with EITHER the `X-Database-Id` header OR the `database_id` body field (exactly one must be given; if both are sent and disagree, that's a 400). Use standard Postgres-compatible SQL; reference the default catalog as `default.<schema>.<table>` (or just `<schema>.<table>` / `<table>`) and attached catalogs by their alias. Results are returned inline and a `result_id` is provided for later retrieval via the Results API.  Set `async: true` to execute asynchronously — returns a query run ID for polling. Optionally set `async_after_ms` to attempt synchronous execution first, falling back to async if the query exceeds the timeout.  To receive the rows as an Arrow IPC stream instead of JSON, send `Accept: application/vnd.apache.arrow.stream` (without also listing `application/json`). A query that completes within the request then returns 200 with an Arrow IPC stream body (schema, record batches, end-of-stream), and the values the JSON body would carry are sent as response headers: `X-Query-Run-Id`, `X-Result-Id` (when the result was saved), `X-Total-Row-Count`, `X-Execution-Time-Ms`, and `X-Query-Warning` (when there is a warning). Arrow keeps `±Inf` and `NaN` float values as they are. An Arrow response always holds the whole result: if the result is larger than an inline response can hold, the request returns 202 with the query run ticket and an `X-Result-Id` header instead, and the full result is read from `GET /v1/results/{id}?format=arrow` once it is ready. A query that goes async, and every error, return the same JSON bodies as without the header.  The endpoint also runs write statements: `INSERT INTO … VALUES … / SELECT …` (append only), `UPDATE … SET … [WHERE …]`, `DELETE FROM … [WHERE …]`, `CREATE TABLE`, `CREATE TABLE … AS SELECT …` and `DROP TABLE`. A write runs once, inline, and answers with a one-row result holding a single `rows_affected` column. Writes need an API key holding both the `read` and `write` permissions, may only target the database's own `default` catalog (attached catalogs stay read-only), and are never run from a saved query. A `DELETE` reports the number of rows its `WHERE` matched and deleted; `DELETE … LIMIT`, `USING` and `RETURNING` are refused. An `UPDATE` reports the number of rows its `WHERE` matched. Each `SET` value is computed from the row as it was before the statement, so `SET a = b, b = a` swaps two values. An `UPDATE` cannot use a table alias, `FROM`, `RETURNING`, `LIMIT` or `ORDER BY`, cannot set one column twice, and cannot set a column that a vector index generates; that column is computed again from its source text. On a table that declares `constant_per_key`, an `UPDATE` cannot set a key column or a `constant_per_key` column. Every other mutation (`ALTER`, views, `COPY`, transactions, `EXPLAIN` of a write) is refused.
 
         :param query_request: (required)
         :type query_request: QueryRequest

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/__init__.py

@@ -113,6 +113,7 @@ from hotdata.models.saved_query_summary import SavedQuerySummary
 from hotdata.models.saved_query_version_info import SavedQueryVersionInfo
 from hotdata.models.submit_job_response import SubmitJobResponse
 from hotdata.models.table_info import TableInfo
+from hotdata.models.table_layout import TableLayout
 from hotdata.models.table_partition_key import TablePartitionKey
 from hotdata.models.table_profile_response import TableProfileResponse
 from hotdata.models.table_sort_key import TableSortKey

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/add_managed_table_decl.py

@@ -20,6 +20,7 @@ import json
 
 from pydantic import BaseModel, ConfigDict, Field, StrictStr
 from typing import Any, ClassVar, Dict, List, Optional
+from hotdata.models.table_layout import TableLayout
 from hotdata.models.table_partition_key import TablePartitionKey
 from hotdata.models.table_sort_key import TableSortKey
 from typing import Optional, Set
@@ -31,10 +32,11 @@ class AddManagedTableDecl(BaseModel):
     """ # noqa: E501
     constant_per_key: Optional[List[StrictStr]] = Field(default=None, description="Columns whose value is determined by this table's `key`: for every uploaded row, every stored row sharing its key holds the same value of these columns.  Declaring this lets a keyed mutation (`delete`, `update`, `upsert`) restrict its search for prior versions to the values the upload carries, which prunes far harder than the key alone when the key's own file statistics are weak. Omit (the default) for the unrestricted search.  **Correctness-affecting, not a hint.** If the assertion is false, a mutation supersedes one version of a key and appends beside another, silently duplicating it. Declare it only where the invariant is established.")
     key: Optional[List[StrictStr]] = Field(default=None, description="Columns that uniquely identify a row, enabling the key-based load modes (`delete`, `update`, `upsert`) on this table: those loads match rows by these columns' values. Omit (the default) to declare no key; the table can still be loaded with `replace` and `append`, but key-based modes are then rejected.")
+    layout: Optional[TableLayout] = Field(default=None, description="Storage layout of the table: `analytical` (the default), or `point_lookup`, which writes small data pages so the table's rows can be fetched by id cheaply, which is what a vector index's answers do; analytical scans of it read more pages. Declared when the table is created and fixed thereafter.")
     name: StrictStr
     partition_by: Optional[List[TablePartitionKey]] = Field(default=None, description="Partition keys for this table, applied in order. Omit for no partitioning. Declared when the table is created and fixed thereafter.")
     sorted_by: Optional[List[TableSortKey]] = Field(default=None, description="Sort keys for this table, applied in order. Omit for no sort order. Declared when the table is created and fixed thereafter. A table with a sort order cannot be indexed: creating any index on it is refused, so leave this empty on a table you plan to search.")
-    __properties: ClassVar[List[str]] = ["constant_per_key", "key", "name", "partition_by", "sorted_by"]
+    __properties: ClassVar[List[str]] = ["constant_per_key", "key", "layout", "name", "partition_by", "sorted_by"]
 
     model_config = ConfigDict(
         populate_by_name=True,
@@ -107,6 +109,7 @@ class AddManagedTableDecl(BaseModel):
         _obj = cls.model_validate({
             "constant_per_key": obj.get("constant_per_key"),
             "key": obj.get("key"),
+            "layout": obj.get("layout"),
             "name": obj.get("name"),
             "partition_by": [TablePartitionKey.from_dict(_item) for _item in obj["partition_by"]] if obj.get("partition_by") is not None else None,
             "sorted_by": [TableSortKey.from_dict(_item) for _item in obj["sorted_by"]] if obj.get("sorted_by") is not None else None

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/add_managed_table_request.py

@@ -20,6 +20,7 @@ import json
 
 from pydantic import BaseModel, ConfigDict, Field, StrictStr
 from typing import Any, ClassVar, Dict, List, Optional
+from hotdata.models.table_layout import TableLayout
 from hotdata.models.table_partition_key import TablePartitionKey
 from hotdata.models.table_sort_key import TableSortKey
 from typing import Optional, Set
@@ -31,10 +32,11 @@ class AddManagedTableRequest(BaseModel):
     """ # noqa: E501
     constant_per_key: Optional[List[StrictStr]] = Field(default=None, description="Columns whose value is determined by this table's `key`: for every uploaded row, every stored row sharing its key holds the same value of these columns.  Declaring this lets a keyed mutation (`delete`, `update`, `upsert`) restrict its search for prior versions to the values the upload carries, which prunes far harder than the key alone when the key's own file statistics are weak. Omit (the default) for the unrestricted search.  **Correctness-affecting, not a hint.** If the assertion is false, a mutation supersedes one version of a key and appends beside another, silently duplicating it. Declare it only where the invariant is established.")
     key: Optional[List[StrictStr]] = Field(default=None, description="Columns that uniquely identify a row, enabling the key-based load modes (`delete`, `update`, `upsert`) on this table: those loads match rows by these columns' values. Omit (the default) to declare no key; the table can still be loaded with `replace` and `append`, but key-based modes are then rejected.")
+    layout: Optional[TableLayout] = Field(default=None, description="Storage layout of the table: `analytical` (the default), or `point_lookup`, which writes small data pages so the table's rows can be fetched by id cheaply, which is what a vector index's answers do; analytical scans of it read more pages. Declared when the table is created and fixed thereafter.")
     name: StrictStr
     partition_by: Optional[List[TablePartitionKey]] = Field(default=None, description="Partition keys for this table, applied in order. Omit for no partitioning. Declared when the table is created and fixed thereafter.")
     sorted_by: Optional[List[TableSortKey]] = Field(default=None, description="Sort keys for this table, applied in order. Omit for no sort order. Declared when the table is created and fixed thereafter. A table with a sort order cannot be indexed: creating any index on it is refused, so leave this empty on a table you plan to search.")
-    __properties: ClassVar[List[str]] = ["constant_per_key", "key", "name", "partition_by", "sorted_by"]
+    __properties: ClassVar[List[str]] = ["constant_per_key", "key", "layout", "name", "partition_by", "sorted_by"]
 
     model_config = ConfigDict(
         populate_by_name=True,
@@ -107,6 +109,7 @@ class AddManagedTableRequest(BaseModel):
         _obj = cls.model_validate({
             "constant_per_key": obj.get("constant_per_key"),
             "key": obj.get("key"),
+            "layout": obj.get("layout"),
             "name": obj.get("name"),
             "partition_by": [TablePartitionKey.from_dict(_item) for _item in obj["partition_by"]] if obj.get("partition_by") is not None else None,
             "sorted_by": [TableSortKey.from_dict(_item) for _item in obj["sorted_by"]] if obj.get("sorted_by") is not None else None

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/database_default_table_decl.py

@@ -20,6 +20,7 @@ import json
 
 from pydantic import BaseModel, ConfigDict, Field, StrictStr
 from typing import Any, ClassVar, Dict, List, Optional
+from hotdata.models.table_layout import TableLayout
 from hotdata.models.table_partition_key import TablePartitionKey
 from hotdata.models.table_sort_key import TableSortKey
 from typing import Optional, Set
@@ -31,10 +32,11 @@ class DatabaseDefaultTableDecl(BaseModel):
     """ # noqa: E501
     constant_per_key: Optional[List[StrictStr]] = Field(default=None, description="Columns whose value is determined by this table's `key`: for every uploaded row, every stored row sharing its key holds the same value of these columns.  Declaring this lets a keyed mutation (`delete`, `update`, `upsert`) restrict its search for prior versions to the values the upload carries, which prunes far harder than the key alone when the key's own file statistics are weak. Omit (the default) for the unrestricted search.  **Correctness-affecting, not a hint.** If the assertion is false, a mutation supersedes one version of a key and appends beside another, silently duplicating it. Declare it only where the invariant is established.")
     key: Optional[List[StrictStr]] = Field(default=None, description="Columns that uniquely identify a row, enabling the key-based load modes (`delete`, `update`, `upsert`) on this table: those loads match rows by these columns' values. Omit (the default) to declare no key; the table can still be loaded with `replace` and `append`, but key-based modes are then rejected.")
+    layout: Optional[TableLayout] = Field(default=None, description="Storage layout of the table: `analytical` (the default), or `point_lookup`, which writes small data pages so the table's rows can be fetched by id cheaply, which is what a vector index's answers do; analytical scans of it read more pages. Declared when the table is created and fixed thereafter.")
     name: StrictStr
     partition_by: Optional[List[TablePartitionKey]] = Field(default=None, description="Partition keys for this table, applied in order. Omit for no partitioning. Declared when the table is created and fixed thereafter.")
     sorted_by: Optional[List[TableSortKey]] = Field(default=None, description="Sort keys for this table, applied in order. Omit for no sort order. Declared when the table is created and fixed thereafter. A table with a sort order cannot be indexed: creating any index on it is refused, so leave this empty on a table you plan to search.")
-    __properties: ClassVar[List[str]] = ["constant_per_key", "key", "name", "partition_by", "sorted_by"]
+    __properties: ClassVar[List[str]] = ["constant_per_key", "key", "layout", "name", "partition_by", "sorted_by"]
 
     model_config = ConfigDict(
         populate_by_name=True,
@@ -107,6 +109,7 @@ class DatabaseDefaultTableDecl(BaseModel):
         _obj = cls.model_validate({
             "constant_per_key": obj.get("constant_per_key"),
             "key": obj.get("key"),
+            "layout": obj.get("layout"),
             "name": obj.get("name"),
             "partition_by": [TablePartitionKey.from_dict(_item) for _item in obj["partition_by"]] if obj.get("partition_by") is not None else None,
             "sorted_by": [TableSortKey.from_dict(_item) for _item in obj["sorted_by"]] if obj.get("sorted_by") is not None else None

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/job_type.py

@@ -38,6 +38,7 @@ class JobType(str, Enum):
     RESULT_RETENTION = 'result_retention'
     DUCKLAKE_COMPACTION = 'ducklake_compaction'
     DUCKLAKE_TABLE_COMPACTION = 'ducklake_table_compaction'
+    IVF_REBALANCE_SWEEP = 'ivf_rebalance_sweep'
     TABLE_CONSTANTS_UPDATE = 'table_constants_update'
     DATABASE_FORK = 'database_fork'
 

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/query_request.py

@@ -33,7 +33,7 @@ class QueryRequest(BaseModel):
     database_id: Optional[StrictStr] = Field(default=None, description="Database to scope the query to (its id). Alternative to the `X-Database-Id` header — exactly one source must be provided. If both this field and the header are set and they disagree, the request is rejected with a 400.")
     default_catalog: Optional[StrictStr] = Field(default=None, description="Catalog that unqualified table references resolve against within the query's database scope. Must name a catalog visible in the database (`default`, an attached catalog alias, or a system catalog). Defaults to `default` when omitted.")
     default_schema: Optional[StrictStr] = Field(default=None, description="Schema that unqualified table references resolve against within the query's database scope.  Omit it to use the database's own default schema — the `default_schema` chosen when the database was created, or the single schema it declares, and only `main` when it has neither. The database's `default_schema` field (see `GET /v1/databases/{id}`) reports the value in force.  Setting this field overrides that per query, so sending `main` on a database whose data lives in another schema turns a query that works without the field into a \"table not found\" error. Existence is not validated up front — an unknown schema surfaces as a \"table not found\" error at planning time. Fully-qualified references (`<catalog>.<schema>.<table>`) are unaffected.")
-    dialect: Optional[StrictStr] = Field(default=None, description="SQL dialect the `sql` field is written in. One of `hotsql` (the default), `duckdb`, `postgres`, or `snowflake`. When set to anything other than `hotsql`, the query is translated to HotSQL before it runs, so you can use idioms from that dialect (for example Snowflake `IFF(...)` or Postgres `MOD(a, b)`). Write statements are accepted on the same terms as in HotSQL: refused unless the instance accepts SQL writes. An unrecognized value is rejected with a 400.")
+    dialect: Optional[StrictStr] = Field(default=None, description="SQL dialect the `sql` field is written in. One of `hotsql` (the default), `duckdb`, `postgres`, or `snowflake`. When set to anything other than `hotsql`, the query is translated to HotSQL before it runs, so you can use idioms from that dialect (for example Snowflake `IFF(...)` or Postgres `MOD(a, b)`). Write statements are accepted on the same terms as in HotSQL. An unrecognized value is rejected with a 400.")
     sql: StrictStr
     __properties: ClassVar[List[str]] = ["async", "async_after_ms", "database_id", "default_catalog", "default_schema", "dialect", "sql"]
 

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata/models/table_info.py

@@ -21,6 +21,7 @@ import json
 from pydantic import BaseModel, ConfigDict, Field, StrictBool, StrictStr
 from typing import Any, ClassVar, Dict, List, Optional
 from hotdata.models.column_info import ColumnInfo
+from hotdata.models.table_layout import TableLayout
 from hotdata.models.table_partition_key import TablePartitionKey
 from hotdata.models.table_sort_key import TableSortKey
 from typing import Optional, Set
@@ -34,12 +35,13 @@ class TableInfo(BaseModel):
     connection: StrictStr
     constant_per_key: List[StrictStr] = Field(description="Columns the table declares constant for a given key: for every row, any other row sharing its key holds the same value of these columns.  Declaring this lets a keyed mutation narrow its search for prior versions to the values the upload carries. Empty when none is declared, which is the unrestricted search.  Unlike `partition_by` and `sorted_by` this is NOT fixed at creation — it changes only which files a mutation opens, never how rows are written — so read it here rather than assuming a declaration took effect.")
     last_sync: Optional[StrictStr] = None
+    layout: TableLayout = Field(description="The table's storage layout: `analytical`, or `point_lookup`, whose small data pages make fetching its rows by id cheap. Fixed at creation.")
     partition_by: List[TablePartitionKey] = Field(description="The table's partition keys, in the order they were declared when the table was created. Empty when the table is not partitioned.  A table's storage layout is fixed when the table is created and cannot be changed afterwards, so this is how to confirm a table really was created with the layout that was asked for. The field is always present: an empty array means \"no partitioning declared\", which is not the same as a response that omits the field entirely.  Reported for tables in a Hotdata instant database, which are the only ones whose layout is declared here. A table discovered from an external connection always reports an empty array — its layout belongs to the upstream system, so an empty array there means \"not known from here\", not \"confirmed unpartitioned\".")
     var_schema: StrictStr = Field(alias="schema")
     sorted_by: List[TableSortKey] = Field(description="The table's sort keys, in the order they were declared when the table was created. Empty when no sort order was declared. Always present, and limited to tables in a Hotdata instant database, for the same reasons as `partition_by`.")
     synced: StrictBool
     table: StrictStr
-    __properties: ClassVar[List[str]] = ["columns", "connection", "constant_per_key", "last_sync", "partition_by", "schema", "sorted_by", "synced", "table"]
+    __properties: ClassVar[List[str]] = ["columns", "connection", "constant_per_key", "last_sync", "layout", "partition_by", "schema", "sorted_by", "synced", "table"]
 
     model_config = ConfigDict(
         populate_by_name=True,
@@ -127,6 +129,7 @@ class TableInfo(BaseModel):
             "connection": obj.get("connection"),
             "constant_per_key": obj.get("constant_per_key"),
             "last_sync": obj.get("last_sync"),
+            "layout": obj.get("layout"),
             "partition_by": [TablePartitionKey.from_dict(_item) for _item in obj["partition_by"]] if obj.get("partition_by") is not None else None,
             "schema": obj.get("schema"),
             "sorted_by": [TableSortKey.from_dict(_item) for _item in obj["sorted_by"]] if obj.get("sorted_by") is not None else None,

hotdata-0.13.0/hotdata/models/table_layout.py

@@ -0,0 +1,38 @@
+# coding: utf-8
+
+"""
+    Hotdata API
+
+    Powerful data platform API for instant databases, queries, and analytics.
+
+    The version of the OpenAPI document: 1.0.0
+    Contact: developers@hotdata.dev
+    Generated by OpenAPI Generator (https://openapi-generator.tech)
+
+    Do not edit the class manually.
+"""  # noqa: E501
+
+
+from __future__ import annotations
+import json
+from enum import Enum
+from typing_extensions import Self
+
+
+class TableLayout(str, Enum):
+    """
+    Storage layout of a table.
+    """
+
+    """
+    allowed enum values
+    """
+    ANALYTICAL = 'analytical'
+    POINT_LOOKUP = 'point_lookup'
+
+    @classmethod
+    def from_json(cls, json_str: str) -> Self:
+        """Create an instance of TableLayout from a JSON string"""
+        return cls(json.loads(json_str))
+
+

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: hotdata
-Version: 0.12.0
+Version: 0.13.0
 Summary: Hotdata API
 Author-email: Hotdata <developers@hotdata.dev>
 License: MIT

{hotdata-0.12.0 → hotdata-0.13.0}/hotdata.egg-info/SOURCES.txt

@@ -136,6 +136,7 @@ hotdata/models/saved_query_summary.py
 hotdata/models/saved_query_version_info.py
 hotdata/models/submit_job_response.py
 hotdata/models/table_info.py
+hotdata/models/table_layout.py
 hotdata/models/table_partition_key.py
 hotdata/models/table_profile_response.py
 hotdata/models/table_sort_key.py
@@ -262,6 +263,7 @@ test/test_saved_query_summary.py
 test/test_saved_query_version_info.py
 test/test_submit_job_response.py
 test/test_table_info.py
+test/test_table_layout.py
 test/test_table_partition_key.py
 test/test_table_profile_response.py
 test/test_table_sort_key.py

{hotdata-0.12.0 → hotdata-0.13.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "hotdata"
-version = "0.12.0"
+version = "0.13.0"
 description = "Hotdata API"
 authors = [
   {name = "Hotdata",email = "developers@hotdata.dev"},

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_add_managed_schema_request.py

@@ -41,6 +41,7 @@ class TestAddManagedSchemaRequest(unittest.TestCase):
                     hotdata.models.add_managed_table_decl.AddManagedTableDecl(
                         constant_per_key = [event_date], 
                         key = [order_id], 
+                        layout = null, 
                         name = 'orders', 
                         partition_by = [
                             hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_add_managed_table_decl.py

@@ -38,6 +38,7 @@ class TestAddManagedTableDecl(unittest.TestCase):
             return AddManagedTableDecl(
                 constant_per_key = [event_date],
                 key = [order_id],
+                layout = 'analytical',
                 name = 'orders',
                 partition_by = [
                     hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_add_managed_table_request.py

@@ -38,6 +38,7 @@ class TestAddManagedTableRequest(unittest.TestCase):
             return AddManagedTableRequest(
                 constant_per_key = [event_date],
                 key = [order_id],
+                layout = 'analytical',
                 name = 'orders',
                 partition_by = [
                     hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_bulk_create_databases_request.py

@@ -49,6 +49,7 @@ class TestBulkCreateDatabasesRequest(unittest.TestCase):
                             hotdata.models.database_default_table_decl.DatabaseDefaultTableDecl(
                                 constant_per_key = [event_date], 
                                 key = [order_id], 
+                                layout = null, 
                                 name = 'orders', 
                                 partition_by = [
                                     hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_create_database_request.py

@@ -48,6 +48,7 @@ class TestCreateDatabaseRequest(unittest.TestCase):
                             hotdata.models.database_default_table_decl.DatabaseDefaultTableDecl(
                                 constant_per_key = [event_date], 
                                 key = [order_id], 
+                                layout = null, 
                                 name = 'orders', 
                                 partition_by = [
                                     hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_database_default_schema_decl.py

@@ -41,6 +41,7 @@ class TestDatabaseDefaultSchemaDecl(unittest.TestCase):
                     hotdata.models.database_default_table_decl.DatabaseDefaultTableDecl(
                         constant_per_key = [event_date], 
                         key = [order_id], 
+                        layout = null, 
                         name = 'orders', 
                         partition_by = [
                             hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_database_default_table_decl.py

@@ -38,6 +38,7 @@ class TestDatabaseDefaultTableDecl(unittest.TestCase):
             return DatabaseDefaultTableDecl(
                 constant_per_key = [event_date],
                 key = [order_id],
+                layout = 'analytical',
                 name = 'orders',
                 partition_by = [
                     hotdata.models.table_partition_key.TablePartitionKey(

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_information_schema_response.py

@@ -53,6 +53,7 @@ class TestInformationSchemaResponse(unittest.TestCase):
                             ''
                             ], 
                         last_sync = '', 
+                        layout = null, 
                         partition_by = [
                             hotdata.models.table_partition_key.TablePartitionKey(
                                 column = 'created_at', 
@@ -87,6 +88,7 @@ class TestInformationSchemaResponse(unittest.TestCase):
                             ''
                             ], 
                         last_sync = '', 
+                        layout = null, 
                         partition_by = [
                             hotdata.models.table_partition_key.TablePartitionKey(
                                 column = 'created_at', 

{hotdata-0.12.0 → hotdata-0.13.0}/test/test_table_info.py

@@ -47,6 +47,7 @@ class TestTableInfo(unittest.TestCase):
                     ''
                     ],
                 last_sync = '',
+                layout = 'analytical',
                 partition_by = [
                     hotdata.models.table_partition_key.TablePartitionKey(
                         column = 'created_at', 
@@ -68,6 +69,7 @@ class TestTableInfo(unittest.TestCase):
                 constant_per_key = [
                     ''
                     ],
+                layout = 'analytical',
                 partition_by = [
                     hotdata.models.table_partition_key.TablePartitionKey(
                         column = 'created_at', 

hotdata-0.13.0/test/test_table_layout.py

@@ -0,0 +1,34 @@
+# coding: utf-8
+
+"""
+    Hotdata API
+
+    Powerful data platform API for instant databases, queries, and analytics.
+
+    The version of the OpenAPI document: 1.0.0
+    Contact: developers@hotdata.dev
+    Generated by OpenAPI Generator (https://openapi-generator.tech)
+
+    Do not edit the class manually.
+"""  # noqa: E501
+
+
+import unittest
+
+from hotdata.models.table_layout import TableLayout
+
+class TestTableLayout(unittest.TestCase):
+    """TableLayout unit test stubs"""
+
+    def setUp(self):
+        pass
+
+    def tearDown(self):
+        pass
+
+    def testTableLayout(self):
+        """Test TableLayout"""
+        # inst = TableLayout()
+
+if __name__ == '__main__':
+    unittest.main()

{hotdata-0.12.0 → hotdata-0.13.0}/tests/test_model_extra_forbid.py

@@ -91,10 +91,13 @@ def test_every_request_body_model_forbids_extras() -> None:
         src = index[cls].read_text()
         if 'extra="forbid"' in src:
             continue
-        # The oneOf/anyOf wrappers carry a different ConfigDict and have no
-        # plain fields to forbid on; anything else must have been patched.
+        # The oneOf/anyOf wrappers carry a different ConfigDict and enums have
+        # no fields at all, so neither has anything to forbid on; anything
+        # else must have been patched.
         if re.search(r"^\s+(oneof|anyof)_schema_\d+_validator", src, re.M):
             continue
+        if re.search(r"^class \w+\(str, Enum\):", src, re.M):
+            continue
         missing.append(cls)
     assert missing == []