feat(tables): add constant-per-key configuration support - #129
feat(tables): add constant-per-key configuration support#129hotdata-automation[bot] wants to merge 1 commit into
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
|
|
||
| ### Changed | ||
|
|
||
| - feat(tables): add constant-per-key configuration support |
There was a problem hiding this comment.
Record the breaking removal of key_determines. Add a ### Removed entry marked **Breaking:**, matching the 0.15.0 entries at CHANGELOG.md lines 41-57.
Release 0.15.0 shipped key_determines on the managed-table declaration models (CHANGELOG.md line 29). This regen renames that field to constant_per_key, adds a required constant_per_key field to TableInfo, and adds a parameter to TableInfo::new. All three changes break downstream compilation.
Failure scenario: a maintainer reads the current note, sees an added feature only, and runs ./scripts/release.sh prepare patch. Version 0.15.1 reaches crates.io. A consumer that sets decl.key_determines = Some(cols) upgrades inside the 0.15 range and fails to compile. No changelog entry explains the break. A crates.io publish is immutable, so the release cannot be corrected in place.
| } | ||
|
|
||
| /// 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 ergonomic wrapper covers either new endpoint (not blocking). src/resources.rs wraps the sibling managed-table operations load_managed_table and delete_managed_table, so a caller on client.connections() cannot reach the constant-per-key write and must call hotdata::apis::connections_api directly. Add wrappers for both new operations in a follow-up.
There was a problem hiding this comment.
Review
Blocking Issues
- CHANGELOG.md line 12: the note records an added feature only. This regen also removes
key_determines, which release 0.15.0 shipped one day ago (CHANGELOG.md line 29), and changes theTableInfo::newsignature. Both changes break downstream crates.
Action Required
- Add a
### Removedentry under the Unreleased heading, marked**Breaking:**. Name thekey_determinestoconstant_per_keyrename onAddManagedTableDecl,AddManagedTableRequestandDatabaseDefaultTableDecl, the new requiredTableInfo.constant_per_keyfield, and the newTableInfo::newparameter. Follow the format of the 0.15.0 entries at CHANGELOG.md lines 41-57. - Ship the change in a minor release, not a patch release.
Notes
- The generated code matches the repository templates. No other code references
key_determinesor constructsTableInfo, so the rename orphans nothing. - The
Integration Tests / integrationcheck was still pending at review time. Compilation is unverified here.
Auto-generated from the updated HotData OpenAPI spec.
Source: https://github.com/hotdata-dev/www/pull/409