chore(databases): clarify fork behavior and error cases - #144
hotdata-automation[bot] wants to merge 1 commit into
Conversation
|
|
||
| ### Changed | ||
|
|
||
| - chore(databases): clarify fork behavior and error cases |
There was a problem hiding this comment.
Document the breaking changes in this bullet list.
Add entries in the style the earlier releases use:
- Breaking:
key_determinesis renamed toconstant_per_keyonAddManagedTableDecl,AddManagedTableRequestandDatabaseDefaultTableDecl. - Breaking:
TableInfogains a requiredconstant_per_keyfield, soTableInfo::newtakes one more argument. - Under
### Added: the twoconstant-per-keyendpoints,UpdateManagedTableRequest,ManagedTableConstantPerKeyResponse, andJobType::TableConstantsUpdate.
Failure scenario: scripts/update_changelog.py copies the [Unreleased] body verbatim into the new version section. The next release therefore ships "clarify fork behavior and error cases" as its entire release note. A caller upgrading from 0.18.0 reads that note, upgrades, and then hits compile errors on key_determines and on TableInfo::new.
key_determines shipped as public API in 0.15.0 (CHANGELOG.md line 73). Releases 0.15.0 and 0.16.0 mark comparable removals with a Breaking: prefix.
| #[serde(rename = "connection")] | ||
| pub connection: String, | ||
| /// 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. | ||
| #[serde(rename = "constant_per_key")] |
There was a problem hiding this comment.
nit: a response that omits constant_per_key now fails to deserialize (not blocking).
Confirm every reachable deployment already returns constant_per_key for each information_schema table. If some deployment omits the field, mark the field optional in the OpenAPI spec rather than patching the generated file.
Serde rejects a missing field when no default is declared. tests/information_schema_read.rs:26 calls .expect, so the scenario test panics against a server that does not send the field. partition_by on line 37 carries the same required shape, so the decision belongs in the spec, not in the generator output.
There was a problem hiding this comment.
Review
Blocking Issues
- CHANGELOG.md:12 — the auto-seeded bullet hides two breaking API changes. The rename of
key_determinestoconstant_per_keyremoves a field released in 0.15.0. The new requiredTableInfo::constant_per_keychanges theTableInfo::newsignature.scripts/update_changelog.pycopies the[Unreleased]body verbatim into the next version section, so the release notes will not mention either change.
Action Required
Rewrite the [Unreleased] entry. List both breaking changes with the Breaking: prefix used in 0.15.0 and 0.16.0. List the new endpoints and models under an Added section.
Notes
One non-blocking comment sits on src/models/table_info.rs:27. Integration Tests / integration was still running when this review started, so its result is not reflected here.
Auto-generated from the updated HotData OpenAPI spec.
Source: https://github.com/hotdata-dev/www/pull/427