chore: improve constant-per-key response documentation - #130
chore: improve constant-per-key response documentation#130hotdata-automation[bot] wants to merge 1 commit into
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| ### Changed | ||
|
|
||
| - chore: improve constant-per-key response documentation |
There was a problem hiding this comment.
This entry omits a breaking API change.
This PR renames key_determines to constant_per_key on AddManagedTableRequest, AddManagedTableDecl, and DatabaseDefaultTableDecl. Release 0.15.0 shipped key_determines as a public field (CHANGELOG.md:29). TableInfo::new also gains a required constant_per_key parameter, and JobType gains a TableConstantsUpdate variant.
Failure scenario: a maintainer reads "chore: improve constant-per-key response documentation" and cuts 0.15.1. A consumer on ^0.15 upgrades and fails to compile on key_determines, on the TableInfo::new arity, and on exhaustive match over JobType.
Fix: mark the rename with **Breaking:**, following the 0.15.0 entries at CHANGELOG.md:41-57. Add the two new endpoints and the two new models under ### Added.
| } | ||
|
|
||
| /// 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, which prunes far harder than the key alone when the key's own file statistics do not discriminate. 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 nothing stored becomes wrong when it changes and a populated table can adopt it with no rewrite. It takes effect on the next load. Send an empty array to revoke it, restoring the unrestricted search — this is the way to undo a declaration that turns out to be false. **This is 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, and the pruning conceals its own evidence because the file holding the missed row is never opened. Declare it only where the invariant is established. | ||
| pub async fn set_managed_table_constant_per_key( |
There was a problem hiding this comment.
nit: no integration test covers the two new constant-per-key endpoints (not blocking).
tests/managed_tables_lifecycle.rs exercises add_managed_schema, add_managed_table, load_managed_table, and delete_managed_table end to end. Without a matching step, a regression in the new PUT path reaches a release unnoticed.
Add a step to that test: set constant_per_key, assert the echoed value, then send [] to revoke.
There was a problem hiding this comment.
Review
Blocking Issues
- CHANGELOG.md:12 — the entry records a documentation change only. The PR renames the public field
key_determinestoconstant_per_keyinsrc/models/add_managed_table_request.rs,src/models/add_managed_table_decl.rs, andsrc/models/database_default_table_decl.rs. Release 0.15.0 shippedkey_determinespublicly.src/models/table_info.rsalso adds a required parameter toTableInfo::new, andsrc/models/job_type.rsadds aJobTypevariant.
Action Required
- Mark the rename as Breaking in CHANGELOG.md, matching the 0.15.0 entries at CHANGELOG.md:41-57.
- List the new endpoints
set_managed_table_constant_per_keyandset_database_table_constant_per_key, plus the modelsUpdateManagedTableRequestandManagedTableConstantPerKeyResponse, under an Added section. - Plan the next release as 0.16.0.
Integration Tests / integration was still running at review time, so no test result is claimed here.
Auto-generated from the updated HotData OpenAPI spec.
Source: https://github.com/hotdata-dev/www/pull/410