mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 17:35:10 +03:00
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Docs fix. ## What is the current behavior? Fixes [SDK-958](https://linear.app/supabase/issue/SDK-958/docs-incomplete-documentation), reported via the docs feedback widget on [joins-and-nesting](https://supabase.com/docs/guides/database/joins-and-nesting). In the "Specifying the `ON` clause for joins with multiple foreign keys" section, the Swift example was broken relative to the other language tabs (JS, Dart, Kotlin, Python, C#): - The query string aliased the second embed as `scans: scan_id_end`, which isn't valid PostgREST embed syntax (should be `end_scan:scans!scan_id_end`). - The `Shift` struct only declared a single `scans: [Scan]` property with no `CodingKeys` entry for `start_scan` or `end_scan` — so it never actually decoded either aliased relation, which is why the reporter couldn't tell where `start_scan` was supposed to come from. ## What is the new behavior? - Query now aliases both relations consistently: `start_scan:scans!scan_id_start (...)` and `end_scan:scans!scan_id_end (...)`, matching the other language examples. - `Shift` struct now declares `startScan: Scan` and `endScan: Scan`, mapped via `CodingKeys` to `start_scan` and `end_scan`. ## Additional context Docs-only change to a code sample inside `apps/docs/content/guides/database/joins-and-nesting.mdx`. Verified with `prettier --check` (mdx lint tool failed locally due to an unrelated missing native module, `node-pty`). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the Swift join example to represent separate start and end scan relationships. * Revised response field selections and coding keys to match the updated relationship names. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Reference Docs
Supabase Reference Docs
Maintainers
If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.
DocSpec
We use documentation specifications which can be used to generate human-readable docs.
- OpenAPI: for documenting API endpoints.
- SDKSpec (custom to Supabase): for SDKs and client libraries.
- ConfigSpec (custom to Supabase): for configuration options.
- CLISpec (custom to Supabase): for CLI commands and usage.
The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.
Contributing
To contribute to docs, see the developers' guide and contributing guide.