fix(schema): V10 schema conversion drops column default values#5508
Open
Ludv1gL wants to merge 1 commit into
Open
fix(schema): V10 schema conversion drops column default values#5508Ludv1gL wants to merge 1 commit into
Ludv1gL wants to merge 1 commit into
Conversation
…0 conversion The From<TableDef> impl hardcoded default_values: Vec::new(), so any V10 serialization of a validated ModuleDef (e.g. the /schema?version=10 endpoint and 'extract-schema') silently dropped all column defaults, while the V9 path preserved them via misc_exports. Emit them from ColumnDef.default_value using the same BSATN encoding the V9 conversion uses, and add a V10 round-trip test. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
impl From<TableDef> for RawTableDefV10hardcodesdefault_values: Vec::new(), so converting a validatedModuleDefback toRawModuleDefV10silently drops every column default. This affects anything that serializes a module's schema as V10 — notably theGET /v1/database/:name_or_identity/schema?version=10endpoint andextract-schema— while?version=9correctly preserves defaults viamisc_exports(RawMiscModuleExportV9::ColumnDefaultValue).Concretely: a table column declared with
#[default(...)]shows up in the V9 schema but its default is absent from the V10 schema, so V10 consumers (schema diff/compat tooling, codegen, migration checks) cannot see defaults at all.The fix mirrors what the V9 conversion already does: emit
default_valuesfromColumnDef::default_value, BSATN-encoding each value (RawColumnDefaultValueV10 { col_id, value }). Validation already round-trips these —ModuleValidatorV10::validate_table_defdecodesdefault_valuesand attaches them to columns — so this closes the loop.Also adds
v10_roundtrip_preserves_column_defaults: builds a module with a column default viaRawModuleDefV10Builder, validates it into aModuleDef, converts back toRawModuleDefV10, and asserts the default survives with the expected encoding.API and ABI breaking changes
None.
RawColumnDefaultValueV10and thedefault_valuesfield already exist in the V10 format and are already consumed by validation; this only populates a field that was previously always empty on the serialization side.Expected complexity level and risk
1 — small, self-contained fix in one conversion impl, plus a unit test.
Testing
cargo test -p spacetimedb-schema --lib: 110 passed, including the new round-trip test.🤖 Generated with Claude Code