TML-2550: elevate explicit-namespace-dsl as a launch-blocking Supabase constituent#664
Conversation
…h-blocking constituent
Reclassify the explicit namespace-aware DSL/ORM surface (TML-2550) from a
deferrable tail unit of target-extensible-ir-namespaces to a required,
launch-blocking constituent of the Supabase integration.
Supabase exposes colliding table names across namespaces (auth.users
alongside public.users). The default-namespace fallback from
runtime-qualification (TML-2605) resolves only one namespace per bare
name, so without explicit qualification there is no way to reach
auth.users -- everything collapses into a single namespace. That is the
user-facing fudge we refuse to ship.
- Add projects/explicit-namespace-dsl/{spec.md,plan.md} as a full
constituent (six framework primitives + one integration project).
- README: add the constituent row (launch blocker), redraw the
dependency graph as a parallel track off the IR foundation feeding
extension-supabase, and fix a stale target-extensible-ir link.
- overview.md: eight capabilities; add the namespace-aware query surface
with the colliding-names rationale and the db.asUser(jwt).sql.auth.users
surface in the request-flow example.
It depends only on TML-2605 and is purely additive on the fallback, so it
runs in parallel and does not gate the IR project close-out.
Signed-off-by: Will Madden <madden@prisma.io>
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (4)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
docs-only replan. Reclassifies the explicit namespace-aware DSL/ORM surface (TML-2550) from a deferrable tail unit of
target-extensible-ir-namespacesinto a required, launch-blocking constituent of the Supabase integration, and gives it a real constituent project directory.Why
A Supabase app queries
auth.*andpublic.*tables that collide by bare name — both schemas ship auserstable. The default-namespace fallback from runtime-qualification (TML-2605) resolves only a single namespace per bare name, so without explicit qualification there is no way to addressauth.users: every namespace collapses into one flat space. That is the user-facing fudge the integration must not ship — hence blocker, not fast-follow.The surface is purely additive on the TML-2605 fallback (default-namespace consumers see zero churn) and depends only on TML-2605, so it runs in parallel and does not gate the IR project close-out.
Changes
projects/explicit-namespace-dsl/{spec.md,plan.md}— mirrors the sibling spec heading set; carries the cross-namespace collision-behaviour decision (union types / qualify-on-collision / compile-error) as the headline open question; plan is one PR, ~2–3 days, four dispatches gated on TML-2605 landing.supabase-integration/README.md— decomposition is now six framework primitives + one integration project; added the constituent row (marked launch blocker); redrew the dependency graph as a parallel track off the IR foundation feedingextension-supabase; fixed a pre-existing staletarget-extensible-ir→target-extensible-ir-namespaceslink.supabase-integration/overview.md— eight capabilities; added the namespace-aware query surface with the colliding-names rationale and thedb.asUser(jwt).sql.auth.usersform in the request-flow example.Linear
Blocker chain wired:
TML-2503(extension-supabase) ←TML-2550(explicit-dsl) ←TML-2605(runtime-qualification). TML-2550 moved into the Supabase Integration project.Scope
Planning docs only — no source, fixtures, or tests touched.