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

docs: resolve OQ-11 and OQ-12 with ADR-015 and ADR-016

Browse Source 
ADR-015: <table> accepts extraConfig prop mirroring Drizzle's third
callback argument for composite unique constraints and other
column-reference-based features.

ADR-016: Adapter accepts Type.Module compiled bundle (not individual
schemas). M.Import() handles ref resolution automatically, eliminating
potential complications with separate schema wiring.

Update FromDbTypeConfig interface to use module instead of schema,
update element types table with extraConfig prop.
This commit is contained in:
glm-5.1
2026-05-23 13:02:23 +00:00
parent 98764086f4
commit da65f7b693
5 changed files with 152 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/architecture/open-questions.md
View File

@@ -100,16 +100,18 @@ Architectural questions for dbtype, organized by theme. Resolved questions refer
### OQ-11: Should `<table>` accept `extraConfig` props?
- **Origin**: [elements.md](elements.md)
- **Status**: Open
- **Priority**: Low
- **Status**: Resolved
- **Priority**: ~~Low~~ Resolved
- **Context**: Drizzle tables accept a third callback argument for indexes and unique constraints defined in terms of column references (e.g., `t => ({ uniqueEmail: unique().on(t.email) })`). The `<index>` element handles most index cases, but composite unique constraints using the Drizzle callback style may not be expressible via `<index unique>`. How should this map to element props, or is it needed at all?
- **Resolution**: Yes — the `<table>` element accepts an `extraConfig` prop that mirrors Drizzle's third callback argument. It receives the rendered column builders and returns an object for indexes, unique constraints, and other column-reference-based features. This is the escape hatch pattern, consistent with `inner` on `<column>`. See [ADR-015](decisions/015-table-extraconfig-props.md).
### OQ-12: Should the adapter accept the Type.Module bundle or individual schemas?
- **Origin**: [repo-adapter.md](repo-adapter.md)
- **Status**: Open
- **Priority**: Low
- **Status**: Resolved
- **Priority**: ~~Low~~ Resolved
- **Context**: The adapter needs access to select, insert, update, and filter schemas. Accepting the `Type.Module` compiled bundle is convenient (everything in one place, accessible via `M.Import()`) but couples the adapter to TypeBox's module format. Accepting individual schemas is more flexible but requires more config. With ADR-010 resolving that derived schemas are included in the module, the module bundle approach is the natural default, but the adapter could expose both interfaces.
- **Resolution**: Accept the Type.Module compiled bundle. `M.Import()` handles ref resolution and recursion automatically, which eliminates potential complications with separate schema wiring. Consistent with ADR-010 (derived schemas in the module) and requires less configuration. See [ADR-016](decisions/016-adapter-accepts-module-bundle.md).
## Summary Table
@@ -125,5 +127,5 @@ Architectural questions for dbtype, organized by theme. Resolved questions refer
| OQ-08 | Per-dialect handler differences | repo-adapter.md | ~~Medium~~ Resolved | **Resolved** — ADR-012 |
| OQ-09 | Relation rendering responsibility | repo-adapter.md | ~~Medium~~ Resolved | **Resolved** — ADR-013 |
| OQ-10 | Migration diffing scope | module.md | ~~Low~~ Resolved | **Resolved** — ADR-014 |
| OQ-11 | Table extraConfig props | elements.md | Low | Open |
| OQ-12 | Module bundle vs. individual schemas | repo-adapter.md | Low | Open |
| OQ-11 | Table extraConfig props | elements.md | ~~Low~~ Resolved | **Resolved** — ADR-015 |
| OQ-12 | Module bundle vs. individual schemas | repo-adapter.md | ~~Low~~ Resolved | **Resolved** — ADR-016 |