docs: call TailorDB schema definitions tables instead of types - #2008
Merged
Conversation
Consistently use "table" instead of "type" across the SDK docs when describing a TailorDB schema definition, matching the db.type() -> db.table() rename. Also fix three leftover db.type(...) code samples in docs/services/tailordb.md that should have read db.table(...).
🦋 Changeset detectedLatest commit: ebdb13d The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
# Conflicts: # packages/sdk-plugin-seed/README.md
@tailor-platform/create-sdk
@tailor-platform/eslint-plugin-sdk
@tailor-platform/sdk
@tailor-platform/sdk-plugin-seed
@tailor-platform/sdk-plugin-tailordb-erd
commit: |
This comment has been minimized.
This comment has been minimized.
![github-actions[bot]](https://avatars.github.com/in/15368?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
… check Follow-up to the previous commit: fix six leftover TailorDB type references the docs-consistency-check CI job pointed out in packages/sdk/docs/plugin/custom.md, packages/sdk/docs/migration/v2.md, packages/create-sdk/templates/tailordb/README.md, and the Supported Schema Changes table in packages/sdk/docs/services/tailordb-migration.md.
This comment has been minimized.
This comment has been minimized.
The v2/idp-publish-events-rename registry entry's description still said "TailorDB types"; update it to "tables" so packages/sdk/docs/migration/v2.md (generated from this registry) stays in sync, fixing the codemod:docs:check CI failure.
This comment has been minimized.
This comment has been minimized.
Fix the plugin/index.md "Types" bullet label that contradicted its own "Additional TailorDB tables" description, reword the ambiguous "Type changes" opening of the migration pre-migration phase to "Schema changes", and rename the deleted-table cleanup note from "types are deleted" to "tables are deleted" in tailordb-migration.md. Also fix a missing "that" in the publishUserEvents migration guide entry (registry.ts, regenerated into v2.md via codemod:docs:update). Left the field-level/type-level hook and index scope terminology unchanged (tailordb.md, tailordb-migration.md) since it is an existing, distinct SDK axis contrasting per-field vs. whole-record configuration, unrelated to the db.type() -> db.table() entity rename -- the same "Type-level" wording is still used to describe the current v2 hooks API in docs/migration/v2.md. Also left the type_removed diff kind reference in tailordb-migration.md:118 as-is, since it already follows the prose/table (type_removed) pattern the docs-consistency-check bot explicitly endorsed.
This comment has been minimized.
This comment has been minimized.
dqn
approved these changes
Aug 7, 2026
dqn
left a comment
dqn
left a comment
Contributor
There was a problem hiding this comment.
LGTM! Two minor questions:
packages/create-sdk/src/context.ts:29 still shows the tailordb template hint as "Comprehensive TailorDB type definitions with all features" — the same sentence this PR updates in templates/tailordb/README.md. Is leaving CLI-facing strings out of scope intentional? (Same wording also remains in the describe title of templates/tailordb/src/db/task.test.ts:7.)
| @@ -0,0 +1,7 @@ | |||
| --- | |||
| "@tailor-platform/sdk": patch | |||
Contributor
There was a problem hiding this comment.
packages/sdk-codemod/src/registry.ts also changed in this PR, but the changeset doesn't bump @tailor-platform/sdk-codemod — intentional?
Contributor
Author
There was a problem hiding this comment.
Fixed in ebdb13d82: added "@tailor-platform/sdk-codemod": patch to the changeset.
The registry.ts fix in the previous commit (chore(codemod): sync migration doc source with the table wording fix) changes published content of @tailor-platform/sdk-codemod but the changeset didn't bump that package. Add a patch entry for it, per review feedback.
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.
Suppressed comments (4)
packages/sdk/docs/services/tailordb.md:359
- This sentence mixes the new “table” terminology with “type-level”. Since this note is describing
.hooks()as a table-level modifier, “type-level” should be “table-level” for consistency within the doc.
**Note:** `.hooks()` can only be called once on a table. Duplicate type-level calls fail at compile time and throw at runtime.
packages/sdk/docs/services/tailordb.md:418
- This note uses “Duplicate type-level calls” even though it’s referring to
.validate()on a table. To keep the terminology consistent, this should say “table-level calls”.
**Note:** `.validate()` can only be called once on a table. Duplicate type-level calls fail at compile time and throw at runtime.
packages/sdk/docs/services/tailordb.md:453
- This paragraph introduces “Table Modifiers”, but still says “type-level configuration”. That reads like a leftover from the “type” terminology; consider changing it to “table-level configuration”.
Table builder methods that set one type-level configuration can be called only once on the same table. Duplicate calls fail at compile time and throw at runtime. This applies to `.description()`, `.hooks()`, `.validate()`, `.features()`, `.indexes()`, `.files()`, `.permission()`, and `.gqlPermission()`.
packages/sdk/docs/services/tailordb-migration.md:343
- This pre-migration description still uses “type-level hooks” and “type-level index changes” after the broader docs terminology shift to “table”. Updating these phrases to “table-level” would keep the section consistent and reduce ambiguity.
1. **Pre-migration**: Schema changes that would be breaking are applied in a relaxed form first. A verified in-place field type change keeps its complete previous field contract until Post-migration, including field and type-level hooks or validators changed by the same migration. Newly-required fields are added as optional; fields whose `optional → required` transition is breaking are temporarily kept optional. Fields that are being removed in this migration are temporarily kept on the table so that `migrate.ts` can still read them (for example, to `innerJoin` through a foreign key that is about to be dropped). Breaking type-level index changes are relaxed the same way: a newly-added unique index is withheld, and an index gaining a unique constraint (or a unique index changing its field set) keeps its previous definition, so `migrate.ts` can resolve duplicates first. Non-breaking changes that are part of the same migration are also applied here.
Code Metrics Report (packages/sdk)
Details | | main (3db5abf) | #2008 (d5f1f41) | +/- |
|--------------------|----------------|-----------------|------|
| Coverage | 78.8% | 78.8% | 0.0% |
| Files | 470 | 470 | 0 |
| Lines | 18537 | 18537 | 0 |
| Covered | 14621 | 14621 | 0 |
| Code to Test Ratio | 1:0.4 | 1:0.4 | 0.0 |
| Code | 132962 | 132962 | 0 |
| Test | 65568 | 65568 | 0 |SDK Configure Bundle Size
Runtime Performance
Type Performance (instantiations)
Reported by octocov |
Contributor
Author
|
Reverted — |
Merged
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
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.
Summary
db.type()->db.table()rename in the v2 migration guide. Prompted by review feedback onpackages/sdk-plugin-seed/README.md.packages/sdk-plugin-seed/README.md,packages/create-sdk/README.md,packages/create-sdk/templates/tailordb/README.md,packages/sdk/docs/migration/v2.md, andpackages/sdk/docs/{configuration,plugin/index,plugin/custom,services/{auth,resolver,executor,tailordb,tailordb-migration}}.md.type:,typeName, hook names likeonTypeLoaded), TS identifiers (TailorDBType, etc.), and literal CLI/diff output (type_added/type_removeddiff kinds,Type 'User':drift output, the.tailor/<plugin-id>/typesdirectory) untouched, since those are stilltype-named in the actual code.db.type(...)code samples indocs/services/tailordb.mdthat should have readdb.table(...).