Skip to content

Commit cf50fa2

Browse files
authored
spelling/grammar fixes + whitelist sqflite (#129)
1 parent 7889007 commit cf50fa2

File tree

6 files changed

+20
-19
lines changed

6 files changed

+20
-19
lines changed

.github/vale/config/vocabularies/PowerSync/accept.txt

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -123,4 +123,5 @@ Yjs
123123
Gradle
124124
npx
125125
cron
126-
nginx
126+
nginx
127+
sqflite

client-sdk-references/javascript-web/javascript-orm/drizzle.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -299,5 +299,5 @@ For watched queries with Drizzle it's recommended to use the `watch()` function
299299
300300
### Table Constraint Restrictions
301301
302-
The Drizzle ORM relies on the underlyng PowerSync table definitions which are subject to certain limitations.
302+
The Drizzle ORM relies on the underlying PowerSync table definitions which are subject to certain limitations.
303303
This means that most Drizzle [constraint features](https://orm.drizzle.team/docs/indexes-constraints) (such as cascading deletes, foreign checks, unique) are currently not supported.

integration-guides/flutterflow-+-powersync/powersync-+-flutterflow-legacy.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -174,7 +174,7 @@ For once, a blank screen means success:
174174
<img src="/images/integration-32.avif"/>
175175
</Frame>
176176
5. Under **"Action Settings"** on the right, add this dependency into "Pubspec Dependencies": `powersync: ^1.8.4`
177-
1. FlutterFlow imports and old version of sqflite by default and it's not possible to remove it, so you also need to add this dependency: `sqflite: ^2.3.3`
177+
1. FlutterFlow imports an old version of sqflite by default and it's not possible to remove it, so you also need to add this dependency: `sqflite: ^2.3.3`
178178
2. Your dependencies should now look as follows:
179179

180180
<Frame>

resources/troubleshooting/error-codes.mdx

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -122,7 +122,7 @@ This reference documents PowerSync error codes organized by component, with trou
122122
- **PSYNC_S1303**:
123123
MongoDB internal TLS error.
124124

125-
If connection to a shared cluster on MongoDB Atlas, this could be an IP Acccess List issue.
125+
If connection to a shared cluster on MongoDB Atlas, this could be an IP Access List issue.
126126
Check that the service IP is allowed to connect to the cluster.
127127

128128
- **PSYNC_S1304**:
@@ -143,7 +143,7 @@ This reference documents PowerSync error codes organized by component, with trou
143143
- **PSYNC_S1307**:
144144
MongoDB authorization error.
145145

146-
Check that the user has the required priviledges.
146+
Check that the user has the required privileges.
147147

148148
- **PSYNC_S1341**:
149149
Sharded MongoDB Clusters are not supported yet.

tutorials/client/attachments-and-files/pdf-attachment.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ keywords: ["pdf", "attachment", "storage"]
88
# Introduction
99

1010
The current version of the [To-Do List demo app](https://github.com/powersync-ja/powersync-js/tree/main/demos/react-native-supabase-todolist) implements a `PhotoAttachmentQueue` class which
11-
enables photo attachments (specifially a `jpeg`) to be synced. This tutorial will guide you on the changes needed to support PDF attachments.
11+
enables photo attachments (specifically a `jpeg`) to be synced. This tutorial will guide you on the changes needed to support PDF attachments.
1212

1313
An overview of the required changes are:
1414
1. Update the app schema by adding a `pdf_id` column to the todos table to link a pdf to a to-do item.

usage/use-case-examples/infinite-scrolling.mdx

Lines changed: 13 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -13,35 +13,35 @@ PowerSync currently [performs well](/resources/performance-and-limits) with sync
1313

1414
This means that in many cases, you can sync a sufficient amount of data to let a user keep scrolling a list or feed that basically feels "infinite" to them.
1515

16-
| Pros | Cons |
17-
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
18-
| It works offline and is low-latency (data loads quickly from the local database). We don't need to load data from the backend via the network when the user reaches the bottom of the page/feed/list. | There will be cases where this approach won't work because the total volume of data might become too large for the local database, for example:There's a wide range of tables that the user needs to be able to infinite scrollYour app allows the user to apply filters to the displayed data, which results in fewer pages displayed from a large dataset, and therefore limited scrolling. |
16+
| Pros | Cons |
17+
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
18+
| It works offline and is low-latency (data loads quickly from the local database). We don't need to load data from the backend via the network when the user reaches the bottom of the page/feed/list. | There will be cases where this approach won't work because the total volume of data might become too large for the local database - for example, when there's a wide range of tables that the user needs to be able to infinite scroll. Your app allows the user to apply filters to the displayed data, which results in fewer pages displayed from a large dataset, and therefore limited scrolling. |
1919

2020
### 2) Control data sync using client parameters
2121

2222
PowerSync supports the use of [client parameters](/usage/sync-rules/advanced-topics/client-parameters) which are specified directly by the client (i.e. not only through the [authentication token](/installation/authentication-setup/custom)). The app can dynamically change these parameters on the client-side and they can be accessed in sync rules on the server-side. The developer can use these parameters to limit/control which data is synced, but since they are not trusted (because they are not passed via the JWT authentication token) they should not be used for access control. You should still filter data by e.g. user ID for access control purposes (using [token parameters](/usage/sync-rules/parameter-queries) from the JWT).
2323

2424
Usage example: To lazy-load/lazy-sync data for infinite scrolling, you could split your data into 'pages' and use a client parameter to specify which pages to sync to a user.
2525

26-
| Pros | Cons |
27-
| --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
28-
| Does not require updating flags in your backend database. Enables client-side control over what data is synced. | We can only sync additional data when the user is online.There will be latency while the user waits for the additional data to sync. |
26+
| Pros | Cons |
27+
| --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
28+
| Does not require updating flags in your backend database. Enables client-side control over what data is synced. | We can only sync additional data when the user is online. There will be latency while the user waits for the additional data to sync. |
2929

3030
### 3) Sync limited data and then load more data from an API
3131

32-
In this scenario we can sync a smaller number of rows to the user initially. And then if the user reaches the end of the page/feed/list, we make an online API call to load additional data from the backend to display to the user.
32+
In this scenario we can sync a smaller number of rows to the user initially. If the user reaches the end of the page/feed/list, we make an online API call to load additional data from the backend to display to the user.
3333

34-
| Pros | Cons |
35-
| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
36-
| This requires syncing less data to each user, which will result in a faster initial sync time. | We can only load additional data when the user is online.There will be some latency to load the additional data (similar to a cloud-first app making API calls)In your app code, records loaded from the API will have to be treated differently from the records loaded from the local SQLite database. |
34+
| Pros | Cons |
35+
| ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
36+
| This requires syncing less data to each user, which will result in a faster initial sync time. | We can only load additional data when the user is online. There will be some latency to load the additional data (similar to a cloud-first app making API calls). In your app code, records loaded from the API will have to be treated differently from the records loaded from the local SQLite database. |
3737

3838
### 4) Client-side triggers a server-side function to flag data to sync
3939

4040
You could add a flag to certain records in your backend database which are used by your [Sync Rules](/usage/sync-rules) to determine which records to sync to specific users. Then your app could make an API call which triggers a function that updates the flags on certain records, causing more records to be synced to the user.
4141

42-
| Pros | Cons |
43-
| ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
44-
| This requires syncing less data to each user, which will result in a faster initial sync time. | We can only perform the trigger and sync additional data when the user is online.There will be higher latency: Both for the API call to update the flags, and for syncing the additional dataWe do not necessarily recommend going this route: There's higher latency and it's not a particularly elegant architecture. |
42+
| Pros | Cons |
43+
| ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
44+
| This requires syncing less data to each user, which will result in a faster initial sync time. | We can only perform the trigger and sync additional data when the user is online. There will be higher latency: Both for the API call to update the flags, and for syncing the additional data. We do not necessarily recommend going this route: There's higher latency and it's not a particularly elegant architecture. |
4545

4646
## Questions, Comments, Suggestions?
4747

0 commit comments

Comments
 (0)