-
-
Notifications
You must be signed in to change notification settings - Fork 235
refactor: rename transcribedText field to transcript #1042
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
braden-w
wants to merge
21
commits into
main
Choose a base branch
from
refactor/transcribedText-to-transcript
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
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
Renames the Recording type's transcribedText field to transcript throughout the data layer to match the already-updated UI labels. This is a breaking change that updates the field name across type definitions, serialization logic, query layer, and all component property accesses.
Contributor
🚀 Preview Deployment Ready!Whispering Preview: https://whispering-pr-1042.epicenter.workers.dev Worker Name: This preview will be automatically updated with new commits to this PR. Built with commit 85f0417 |
This adds the migration infrastructure needed to support the transcribedText → transcript rename from PR #1042. Without this, existing user data would break on upgrade. The Recording type now includes a version field (version: 7), and a migration pipeline validates and upgrades V6 records (with transcribedText) to V7 (with transcript). The Dexie migration (v0.7) handles IndexedDB upgrades, while desktop markdown storage simply constructs recordings with the current version on read.
… validator Renamed RecordingMigrator to Recording and inlined the migration logic in the pipe callback to match the established pattern in transformations.ts. The pipe now explicitly returns RecordingV7 rather than the Recording alias. Removed the validateAndMigrateRecording wrapper as it's no longer needed.
Changed RecordingV7 type to use typeof infer pattern, matching how TransformationStepV2 is defined in transformations.ts. The "Two different types with this name exist" errors are pre-existing (56 errors) and affect all arktype types in this codebase, not specific to Recording.
…or for parsing Updates the V7 migration in web.ts to use Dexie's .modify() method instead of clear/bulkAdd, which is safer for in-place record updates and avoids potential data loss if the migration fails partway through. For file-system.ts, replaces the separate RecordingFrontMatter validator with the Recording validator itself, allowing desktop files to benefit from the same automatic V6→V7 migration as web storage. The parseMarkdownToRecording function now combines frontmatter and body, then validates through Recording which handles schema versioning automatically. Also adds clarifying comments distinguishing Dexie schema versions (0.1-0.7) from Recording schema versions (V6-V7) to prevent future confusion.
Updates V4 migration (adding createdAt/updatedAt) to use Dexie's .modify() for simpler in-place field additions. V5 migration (blob→ArrayBuffer) remains using clear/bulkAdd since the async blob conversion is more complex and the existing pattern is battle-tested. Added comment explaining this decision. V7 migration already uses .modify() from the previous commit.
… validator Desktop files are treated as V6 schema. The Recording validator handles defaulting version to 6 and migrating to V7 automatically. No need to manually set version or check frontmatter fields.
Changes parseMarkdownToRecording to return a wellcrafted Result type instead of a union type. The error variant includes the validation summary for better error reporting.
Adds detailed documentation explaining that the Recording validator accepts V6 or V7 input and always outputs the latest schema (V7). Includes usage example in the JSDoc.
Each RecordingsDbSchema type is now a complete, self-contained definition showing exactly what the data looked like at that Dexie version. No longer derived from current types, so changes to Recording won't affect historical schema definitions. This makes the migration history clear and prevents type drift.
Exports RecordingV6 and RecordingV7 types, then uses them to derive RecordingsDbSchemaV5 and RecordingsDbSchemaV6. This keeps the current schemas in sync with the validators while V4 and earlier remain as frozen snapshots.
V0.5 migration now sets version: 6 explicitly, and V0.7 migration uses hardcoded 7 instead of CURRENT_RECORDING_VERSION. This ensures migration code is self-documenting and doesn't depend on external constants that could change.
…ines - New article: freezing-schema-types-for-migrations.md explains why historical schema types should be explicit snapshots, not derived from current types - Updated documentation.md with refined technical article guidelines: section titles should contain the insight, openings can be personal if they get to the point quickly, banner comments help scanability
Removed the separate migrateStepV1ToV2 function and inlined the migration directly in the .pipe() callback. This follows the pattern of keeping simple transformations close to where they're used. Updated the migrate-on-read article to reflect this simpler approach.
- Make TransformationStepV1 and TransformationStepV2 internal (not exported) - Derive TransformationStep type from Transformation['steps'][number] - Change web.ts to use TransformationV2['steps'] instead of TransformationStepV2[] - Simplify migration pipe by checking V2 first for proper type narrowing - Remove TransformationBase intermediate type (inline fields into V1/V2) - Convert TransformationV1 from type alias to arktype validator
Updated both migration articles to use Recording as the primary example instead of TransformationStep since it's simpler. Added cross-references between the articles and removed the Composing Validators section.
feat(db): add Recording schema versioning and V6→V7 migration
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This renames the Recording type's
transcribedTextfield totranscriptthroughout the data layer. The UI layer (labels, component names, dialog titles) had already been updated, but the underlying data field still used the old name. This creates consistency between the user-facing terminology and the codebase internals.The change touches 12 files across type definitions, serialization logic, query layer mutations, and component property accesses. Because this is a breaking change to the Recording type, all updates needed to happen atomically.
Key areas updated:
models/recordings.tsfile-system.ts(frontmatter + body pattern)transcription.ts,actions.ts,transformer.ts)propertyNameidentifiersaccessorKeyconfigurationsNote: README documentation files contain example code snippets that still reference
transcribedText. These are illustrative examples and updating them is optional since they don't affect runtime behavior.