Documentation edits made through Mintlify web editor

Author: benitav

usage/sync-rules/organize-data-into-buckets.mdx

@@ -9,6 +9,7 @@ Each user can sync a number of buckets (up to 1,000), and each bucket defines a
 This is defined using two queries:
 
 1. Select bucket parameters from a user ID and/or other parameters ([parameter queries](/usage/sync-rules/parameter-queries))
+
 2. Select data in the bucket using the bucket parameters ([data queries](/usage/sync-rules/data-queries))
 
 When designing your buckets, it is recommended, but not required, to group all data in a bucket where the same parameters apply.
@@ -17,7 +18,7 @@ An example:
 
 ```yaml
 bucket_definitions:
-  user_buckets:
+  user_lists:
     # Select parameters for the bucket, using the current user_id
     # (request.user_id() comes from the JWT token)
     parameters: SELECT request.user_id() as user_id
@@ -28,4 +29,4 @@ bucket_definitions:
 
 <Info>
   **Note**: Table names within Sync Rules must match the names defined in the [client-side schema](/installation/client-side-setup/define-your-schema).
-</Info>
+</Info>

usage/sync-rules/parameter-queries.mdx

@@ -7,14 +7,14 @@ Parameter queries allow parameters to be defined on a bucket to group data. Thes
 ```yaml
 bucket_definitions:
   # Bucket Name
-  user_buckets:
+  user_lists:
     # Parameter Query
     parameters: SELECT request.user_id() as user_id
     # Data Query
     data:
       - SELECT * FROM lists WHERE lists.owner_id = bucket.user_id
 
-  user_table_buckets:
+  user_lists_table:
     # Similar query, but using a table
     # Access can instantly be revoked by deleting the user row/document
     parameters: SELECT id as user_id FROM users WHERE users.id = request.user_id()
@@ -25,7 +25,9 @@ bucket_definitions:
 Available functions in sync rules are:
 
 1. `request.user_id()`: Returns the JWT subject, same as `request.jwt() ->> 'sub'`
+
 2. `request.jwt()`: Returns the entire (signed) JWT payload as a JSON string.
+
 3. `request.parameters()`: Returns [client parameters](/usage/sync-rules/advanced-topics/client-parameters) as a JSON string.
 
 Example usage:
@@ -63,16 +65,21 @@ request.jwt() ->> 'app_metadata.custom_field' -- custom field added by a service
   The new functions available in sync rules are:
 
   1. `request.jwt()`: Returns the entire (signed) JWT payload as a JSON string.
+
   2. `request.parameters()`: Returns [client parameters](/usage/sync-rules/advanced-topics/client-parameters) as a JSON string.
+
   3. `request.user_id()`: Returns the token subject, same as `request.jwt() ->> 'sub'` and also the same as `token_parameters.user_id` in the previous syntax.
 
   The major difference from the previous `token_parameters` is that all payloads are preserved as-is, which can make usage a little more intuitive. This also includes JWT payload fields that were not previously accessible.
 
   Migrating to the new syntax:
 
   1. `token_parameters.user_id` references can simply be updated to `request.user_id()`
+
   2. Custom parameters can be updated from `token_parameters.my_custom_field` to `request.jwt() ->> 'parameters.my_custom_field'`
+
      1. This example applies if you keep your existing custom JWT as is.
+
      2. Supabase users can now make use of [Supabase's standard JWT structure](https://supabase.com/docs/guides/auth/jwts#jwts-in-supabase) and reference `app_metadata.my_custom_field` directly.
 
   Example:
@@ -210,6 +217,9 @@ The supported SQL is based on a small subset of the SQL standard syntax.
 Notable features and restrictions:
 
 1. Only simple `SELECT` statements are supported.
+
 2. No `JOIN`, `GROUP BY` or other aggregation, `ORDER BY`, `LIMIT`, or subqueries are supported.
+
 3. For token parameters, only `=` operators are supported, and `IN` to a limited extent.
+
 4. A limited set of operators and functions are supported — see [Operators and Functions](/usage/sync-rules/operators-and-functions).