alkdev/dbtype
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: resolve all open architecture questions with ADRs 009-014

Browse Source 
Resolve OQ-01 through OQ-10 with formal ADRs and update all architecture
docs to reference decisions. Add two new tracked questions (OQ-11, OQ-12)
surfaced during review.

ADR-009: Keep FooRelations naming convention for relation entries
ADR-010: One module per database, include derived schemas by default
ADR-011: Support JSX/TSX as ergonomic authoring layer
ADR-012: Always .returning() with graceful fallback per dialect
ADR-013: Adapter generates relations from module entries (no <relation> element)
ADR-014: Leverage drizzle-kit for migrations, no native migration generator

Also upgrades elements.md, hosts.md, repo-adapter.md status to stable,
clarifies OQ-06 as design clarification, and specifies MySQL .returning()
detection mechanism in ADR-012.
This commit is contained in:
glm-5.1
2026-05-23 12:47:55 +00:00
parent d4fd67f4d2
commit 98764086f4
12 changed files with 481 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/architecture/schema.md
View File

@@ -82,11 +82,11 @@ Per-column comparison operators derived from the column type. Generated by the r
## Open Questions
1. **Should relation entries use a naming convention?** Currently `UsersRelations` / `TasksRelations`. Is this sufficient, or should relations be structured differently (e.g., a `relations` field on the table entry)?
1. ~~**Should relation entries use a naming convention?**~~ **Resolved — ADR-009**. Keep the `FooRelations` naming convention. Separate module entries for relations align with Drizzle's naming, stay within the module's flat namespace, and are independently addressable.
2. **Derived schemas in the module or separate?** Insert/update schemas can be added as module entries (`InsertUsers`, `UpdateUsers`) or extracted by walking the module schema. Which is cleaner for the repo adapter?
2. ~~**Derived schemas in the module or separate?**~~ **Resolved — ADR-010**. Include all derived schemas (insert, update, filter) in the module by default. A `repo_from` interface will generate CRUD operation specs from the module using the operations system. An `includeDerived: false` opt-out can be added later if needed.
3. **Should the module support multiple databases?** One module per database, or one module with all tables across all databases? Probably one per database namespace.
3. ~~**Should the module support multiple databases?**~~ **Resolved — ADR-010**. One module per database namespace. This keeps the module's flat namespace clean, avoids table name collisions, and aligns with Drizzle's schema organization.
## References