diff --git a/client-sdks/advanced/attachments.mdx b/client-sdks/advanced/attachments.mdx index 943b8fa2..bee9c987 100644 --- a/client-sdks/advanced/attachments.mdx +++ b/client-sdks/advanced/attachments.mdx @@ -61,7 +61,7 @@ Most demo applications use Supabase Storage as the storage provider, but the pat |-------|-------------| | `QUEUED_UPLOAD` | File saved locally, waiting to upload to remote storage | | `QUEUED_DOWNLOAD` | Data model synced from another device, file needs to be downloaded | -| `SYNCED` | File exists both locally and in remote storage, fully synchronized | +| `SYNCED` | File exists both locally and in remote storage, fully synced | | `QUEUED_DELETE` | Marked for deletion from both local and remote storage | | `ARCHIVED` | No longer referenced in your data model, candidate for cleanup | @@ -141,7 +141,7 @@ The queue needs to know which attachments exist in your data model. The `watchAt - **Missing attachments** - Upload them - **Removed attachments** - Archive them -The `watchAttachments` queries are reactive and execute whenever the watched tables change, keeping the attachment queue synchronized with your data model. +The `watchAttachments` queries are reactive and execute whenever the watched tables change, keeping the attachment queue in sync with your data model. There are a few scenarios you might encounter: diff --git a/client-sdks/advanced/local-only-usage.mdx b/client-sdks/advanced/local-only-usage.mdx index 89e66d33..0010be38 100644 --- a/client-sdks/advanced/local-only-usage.mdx +++ b/client-sdks/advanced/local-only-usage.mdx @@ -11,7 +11,7 @@ A caveat is that if the user never registers, this queue will keep on growing in There are two general approaches we recommend for this: -### 1\. Local-only tables +### 1\. Local-Only Tables @@ -77,7 +77,7 @@ The following example implementations are available: | Flutter To-Do List App (with Supabase) | [supabase-todolist-optional-sync](https://github.com/powersync-ja/powersync.dart/tree/main/demos/supabase-todolist-optional-sync) | | React To-Do List App (with Supabase) | [react-supabase-todolist-optional-sync](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-supabase-todolist-optional-sync) | -### 2\. Clearing the upload queue +### 2\. Clearing the Upload Queue The upload queue can be cleared periodically (for example on every app start-up), avoiding the growth in database size over time. This can be done using: diff --git a/client-sdks/advanced/sequential-id-mapping.mdx b/client-sdks/advanced/sequential-id-mapping.mdx index 91183511..3be97bcc 100644 --- a/client-sdks/advanced/sequential-id-mapping.mdx +++ b/client-sdks/advanced/sequential-id-mapping.mdx @@ -90,7 +90,7 @@ We can achieve this by creating SQL triggers. ## Create SQL Triggers We need to create triggers that can look up the integer ID for the given UUID and vice versa. -These triggers will maintain consistency between `list_id` and `list_uuid` in the `todos` table by ensuring that they remain synchronized with the `id` and `uuid` columns in the `lists` table; +These triggers will maintain consistency between `list_id` and `list_uuid` in the `todos` table by ensuring that they remain in sync with the `id` and `uuid` columns in the `lists` table; even if changes are made to either field. We will create the following two triggers that cover either scenario of updating the `list_id` or `list_uuid` in the `todos` table: diff --git a/client-sdks/advanced/unit-testing.mdx b/client-sdks/advanced/unit-testing.mdx index b6d7b7b4..558af45c 100644 --- a/client-sdks/advanced/unit-testing.mdx +++ b/client-sdks/advanced/unit-testing.mdx @@ -65,7 +65,9 @@ test('INSERT', () async { }); ``` -#### If you have trouble with loading the extension, confirm the following +### Troubleshooting Extension Loading + +If you have trouble loading the extension, confirm the following: Ensure that your SQLite3 binary install on your system has extension loading enabled. You can confirm this by doing the following diff --git a/sync/advanced/sharded-databases.mdx b/sync/advanced/sharded-databases.mdx index 7314c586..afde1abe 100644 --- a/sync/advanced/sharded-databases.mdx +++ b/sync/advanced/sharded-databases.mdx @@ -20,27 +20,27 @@ Where feasible, using separate PowerSync Service instances would give better per Some specific scenarios: -#### 1\. Different tables on different databases +#### 1\. Different Tables on Different Databases This is common when separate "services" use separate databases, but multiple tables across those databases need to be synced to the same users. Use a single PowerSync Service instance, with a separate connection for each source database ([planned](https://roadmap.powersync.com/c/84-support-for-sharding-multiple-database-connections); this capability will be available in a future release). Use a unique [connection tag](/sync/advanced/schemas-and-connections) for each source database, allowing them to be distinguished in your [Sync Streams](/sync/streams/overview) or [Sync Rules](/sync/rules/overview). -#### 2a. All data for any single customer is contained in a single shard +#### 2a. All Data for a Single Customer Is Contained in a Single Shard This is common when sharding per customer account / organization. In this case, use a separate PowerSync Service instance for each database. -#### 2b. Most customer data is in a single shard, but some data is in a shared database +#### 2b. Most Customer Data Is in a Single Shard, but Some Data Is in a Shared Database If the amount of shared data is small, still use a separate PowerSync Service instance for each database, but also add the shared database connection to each PowerSync Service instance using a separate connection tag ([planned](https://roadmap.powersync.com/c/84-support-for-sharding-multiple-database-connections); this capability will be available in a future release). -#### 2c. Data for a single customer is split across multiple shards +#### 2c. Data for a Single Customer Is Split Across Multiple Shards This is more complicated than the other cases listed above. Please [reach out to us](/resources/contact-us) if this is your architecture. -#### 3\. Only some tables are sharded +#### 3\. Only Some Tables Are Sharded In some cases, most tables would be on a shared server, with only a few large tables being sharded.