chore(uploads): document 16 GiB upload size limit - #137
chore(uploads): document 16 GiB upload size limit#137hotdata-automation[bot] wants to merge 1 commit into
Conversation
|
|
||
| ### Changed | ||
|
|
||
| - chore(uploads): document 16 GiB upload size limit |
There was a problem hiding this comment.
The Unreleased section omits every breaking change in this diff.
Failure scenario: a caller on 0.16.0 sets key_determines on AddManagedTableRequest. CHANGELOG.md:38 documents that field as a 0.15.0 addition. The caller upgrades and the build fails with no field named key_determines. The changelog names only an upload doc edit, so the rename is invisible.
Add entries for the following, using the **Breaking:** marker already used at CHANGELOG.md:50, :56, :59 and :63.
- Breaking:
key_determinesis renamed toconstant_per_keyonAddManagedTableDecl,AddManagedTableRequestandDatabaseDefaultTableDecl. - Breaking:
TableInfogains a requiredconstant_per_keyfield, soTableInfo::newtakes one more argument. - Breaking:
JobTypegains theTableConstantsUpdatevariant.JobTypeis not#[non_exhaustive], so a downstream exhaustive match stops compiling. - Added:
set_managed_table_constant_per_key,set_database_table_constant_per_key,ManagedTableConstantPerKeyResponseandUpdateManagedTableRequest.
CI does not catch this. scripts/check-release.py:63 returns early while the Cargo.toml version is unchanged.
| } | ||
|
|
||
| /// Replace the columns a 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 (`delete`, `update`, `upsert`) narrow its search for prior versions to the values the upload carries. Unlike `partition_by` and `sorted_by`, this is NOT fixed when the table is created — it changes only which files a mutation opens, never how rows are written — so a populated table can adopt it with no rewrite, taking effect on the next load. Send an empty array to revoke it. **Correctness-affecting, not a hint.** If the assertion is false, a keyed mutation supersedes one version of a key and appends beside another, silently duplicating it. Declare it only where the invariant is established. | ||
| pub async fn set_database_table_constant_per_key( |
There was a problem hiding this comment.
nit: the two new constant-per-key operations reach no wrapper in src/resources.rs (not blocking).
Callers must reach into apis::databases_api directly, while comparable operations get a wrapper — databases().lookup_by_name at src/resources.rs:198 wraps lookup_database_by_name. Consider adding databases().set_table_constant_per_key and the connection-scoped equivalent.
There was a problem hiding this comment.
Review
Blocking Issues
- CHANGELOG.md:12 — the Unreleased section records only the upload doc edit. The diff also renames
key_determinestoconstant_per_keyon three request models, adds a requiredconstant_per_keyfield toTableInfo, adds aJobTypevariant, and adds two endpoints with two models. Each rename and signature change breaks downstream compilation silently.
Action Required
- Expand the Unreleased section to list the breaking changes with the
**Breaking:**marker used at CHANGELOG.md:50, :56, :59 and :63. - List the new endpoints and models under an Added subsection.
Note on CI: the Check release metadata job passes here regardless. scripts/check-release.py:63 returns early while the Cargo.toml version is unchanged.
One non-blocking nit is inline on src/apis/databases_api.rs.
Auto-generated from the updated HotData OpenAPI spec.
Source: https://github.com/hotdata-dev/www/pull/425