From 0638dd9d9d1083e0972eea9b2fe9c434dc02cef5 Mon Sep 17 00:00:00 2001 From: JarWarren Date: Sun, 24 Nov 2024 22:02:21 -0700 Subject: [PATCH] typos --- docs/src/content/docs/comparison/supabase.mdx | 4 ++-- docs/src/content/docs/documentation/APIs/record_apis.mdx | 6 +++--- docs/src/content/docs/documentation/auth.mdx | 2 +- docs/src/content/docs/documentation/extending.mdx | 2 +- docs/src/content/docs/documentation/production.mdx | 2 +- docs/src/content/docs/getting-started/starting-up.mdx | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/src/content/docs/comparison/supabase.mdx b/docs/src/content/docs/comparison/supabase.mdx index 702cf710..ba9cdea6 100644 --- a/docs/src/content/docs/comparison/supabase.mdx +++ b/docs/src/content/docs/comparison/supabase.mdx @@ -9,10 +9,10 @@ architecturally. For one, both Postgres and SupaBase are heck of a lot more modular. "Rule 34" of the database world: if you can think of it, there's a Postgres extension for it. -And SupaBase doesn't an excellent job at making all that flexibility available +And SupaBase does an excellent job at making all that flexibility available without getting in the way and giving you untethered access while further expanding upon it. -In many ways, TrailBase is trying to evnetually do the same for SQLite: +In many ways, TrailBase is trying to eventually do the same for SQLite: combining PocketBase's simplicity with SupaBase's layering. One foundational difference is that Postgres itself is a multi-user, diff --git a/docs/src/content/docs/documentation/APIs/record_apis.mdx b/docs/src/content/docs/documentation/APIs/record_apis.mdx index c60602bb..0a374ce4 100644 --- a/docs/src/content/docs/documentation/APIs/record_apis.mdx +++ b/docs/src/content/docs/documentation/APIs/record_apis.mdx @@ -4,7 +4,7 @@ title: Record APIs import { Aside } from "@astrojs/starlight/components"; -The easiest and most type-safe path to access you `TABLE`s and `VIEW`s is to use +The easiest and most type-safe path to access your `TABLE`s and `VIEW`s is to use TrailBase's restful CRUD _Record APIs_. The only requirements are: @@ -111,7 +111,7 @@ update but are hidden on reads. This is meant as a convenient convention to allow for internal data fields, e.g hiding the record owner in an otherwise public data set or hiding a user's internal credit rating from their profile. A similar effect could otherwise be achieved by exposing a table for inserts and -updates only while poxying reads through a VIEW. +updates only while proxying reads through a VIEW.