Skip to content

Commit 6081973

Browse files
authored
Merge branch 'docs' into fix-typo
2 parents f815a39 + eaf4a08 commit 6081973

File tree

1 file changed

+31
-15
lines changed

1 file changed

+31
-15
lines changed

resources/faq.mdx

Lines changed: 31 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -8,62 +8,78 @@ mode: wide
88
<Accordion title="What versions of Postgres are supported?">
99
PowerSync supports Postgres 11+
1010
</Accordion>
11+
1112
<Accordion title="How is a client-side sync triggered? Does the SDK use polling or real-time sync?">
12-
**PowerSync uses near real-time streaming of changes to the client (< 1s delay).**
13+
**PowerSync uses near real-time streaming of changes to the client (\< 1s delay).**
1314

14-
A persistent connection is used to continuously stream changes to the client.
15+
A persistent connection is used to continuously stream changes to the client.
1516

16-
The is implemented using a standard HTTP/2 request with a streaming response, or WebSockets.
17+
The is implemented using a standard HTTP/2 request with a streaming response, or WebSockets.
1718

18-
A polling API will also be available for cases where the client only needs to update data periodically, and prefer to not keep a connection open.
19+
A polling API will also be available for cases where the client only needs to update data periodically, and prefer to not keep a connection open.
1920

20-
The real-time streaming is not designed for "update as you type" — it still depends on explicitly saving changes. Real-time collaboration is supported as long as users do not edit the same data (same columns of the same rows) at the same time.
21+
The real-time streaming is not designed for "update as you type" — it still depends on explicitly saving changes. Real-time collaboration is supported as long as users do not edit the same data (same columns of the same rows) at the same time.
2122

22-
Concurrently working on text documents is not supported out of the box. This is solved better by CRDTs — see the [CRDTs](/usage/use-case-examples/crdts) section.
23+
Concurrently working on text documents is not supported out of the box. This is solved better by CRDTs — see the [CRDTs](/usage/use-case-examples/crdts) section.
2324
</Accordion>
25+
2426
<Accordion title="What data volumes are supported?">
2527
See the section on [Performance and Limits](/resources/performance-and-limits).
2628
</Accordion>
29+
2730
<Accordion title="What happens when a user is offline for a long time?">
28-
If no sync rule changes were deployed in this period, the user will only need to download the incremental changes that happened since the user was last connected.
31+
If no sync rule changes were deployed in this period, the user will only need to download the incremental changes that happened since the user was last connected.
2932
</Accordion>
33+
3034
<Accordion title="Can a client track whether changes have been processed?">
31-
_For example, a new record should not be displayed until the server received it, or it should be displayed as pending, or the entire screen must block with a spinner._
35+
*For example, a new record should not be displayed until the server received it, or it should be displayed as pending, or the entire screen must block with a spinner.*
3236

33-
**While PowerSync does not have out-of-the-box support for this due to the great variety of requirements, this is easy to build on top of the sync system.** A simple approach is to store a “status” or “pending changes” column on the table, and set that whenever the client makes a change. When the server receives the change, it then sets it to “processed” / “no pending changes”. So when the server has processed the change, the client automatically syncs that status back.For more granular information, record individual changes in a separate table, as explained in [Custom Conflict Resolution](/usage/lifecycle-maintenance/handling-update-conflicts/custom-conflict-resolution).Note: Blocking the entire screen with a spinner is not recommended, since the change may take a very long time to be processed if the user is offline.
37+
**While PowerSync does not have out-of-the-box support for this due to the great variety of requirements, this is easy to build on top of the sync system.** A simple approach is to store a “status” or “pending changes” column on the table, and set that whenever the client makes a change. When the server receives the change, it then sets it to “processed” / “no pending changes”. So when the server has processed the change, the client automatically syncs that status back.For more granular information, record individual changes in a separate table, as explained in [Custom Conflict Resolution](/usage/lifecycle-maintenance/handling-update-conflicts/custom-conflict-resolution).Note: Blocking the entire screen with a spinner is not recommended, since the change may take a very long time to be processed if the user is offline.
3438
</Accordion>
39+
3540
<Accordion title="I don’t have direct database access, and can only access data via an API. Can I use PowerSync for this?">
3641
**Right now, we don’t have support for replicating data via APIs.** A workaround would be to have custom code to replicate the data from the API to a PostgreSQL instance, then sync that with PowerSync.We may add a way in the future to replicate the data directly from an API to the PowerSync service, without a database in between.
3742
</Accordion>
43+
3844
<Accordion title="Are “live queries” supported?">
39-
**Yes.**The PowerSync client SDKs support real-time streaming of changes, and can automatically rerun a query if the underlying data changed.It does not support incrementally updating the result set yet, but it should be fast if the query is indexed appropriately, and the result set is small enough.
45+
\*\*Yes.\*\*The PowerSync client SDKs support real-time streaming of changes, and can automatically rerun a query if the underlying data changed.It does not support incrementally updating the result set yet, but it should be fast if the query is indexed appropriately, and the result set is small enough.
4046
</Accordion>
47+
4148
<Accordion title="What features are available for debugging issues?">
4249
See [Troubleshooting](/resources/troubleshooting)
4350
</Accordion>
51+
4452
<Accordion title="Are transactions supported?">
4553
**Client-side transactions are supported**, and use standard SQLite locking to avoid conflicts.**Client-server transactions are not supported.** This would require online connectivity to detect conflicts and retry the transaction, which is not possible for changes made offline. Instead, it is recommended to model the data to allow atomic changes (see previous sections on conflict detection).
4654
</Accordion>
55+
4756
<Accordion title="Can auto-incrementing IDs be used?">
4857
**This is generally not recommended, but it can be used in some cases, with caveats.**
4958

5059
See the section on [client ID](/usage/sync-rules/client-id) for details.
5160
</Accordion>
61+
5262
<Accordion title="Can attachments (files) be synced?">
5363
**An attachment sync or caching system can be built on top of PowerSync.**
5464

55-
See the section on [Attachments](/usage/use-case-examples/attachments-files) for details.
65+
See the section on [Attachments](/usage/use-case-examples/attachments-files) for details.
5666
</Accordion>
67+
5768
<Accordion title="My backend application uses GraphQL. Can I use PowerSync?">
5869
Currently, PowerSync can only read from Postgres databases directly. GraphQL or REST APIs can be used for the write path by the PowerSync SDK
5970
</Accordion>
71+
6072
<Accordion title="Is the system susceptible to SQL Injection?">
61-
By default PowerSync is not susceptible to SQL injection. The PowerSync execute API is parameterized, and as long as developers use that, SQL injection is not possible. It is however the developer's responsibility to ensure that they use the parameterized API and don't directly insert user-provided data into underlying SQLite tables.
73+
By default PowerSync is not susceptible to SQL injection. The PowerSync execute API is parameterized, and as long as developers use that, SQL injection is not possible. It is however the developer's responsibility to ensure that they use the parameterized API and don't directly insert user-provided data into underlying SQLite tables.
6274
</Accordion>
63-
<Accordion title="When should I use getCrudBatch() instead of getNextCrudTransaction() ?">
6475

76+
<Accordion title="When should I use getCrudBatch() instead of getNextCrudTransaction() ?">
6577
[getCrudBatch()](https://pub.dev/documentation/powersync/latest/powersync/PowerSyncDatabase/getCrudBatch.html) [getNextCrudTransaction()](https://pub.dev/documentation/powersync/latest/powersync/PowerSyncDatabase/getNextCrudTransaction.html)
6678

67-
Use getCrudBatch() when you don't care about atomic transactions, and want to do bulk updates for performance reasons.
79+
Use getCrudBatch() when you don't care about atomic transactions, and want to do bulk updates for performance reasons.
80+
</Accordion>
81+
82+
<Accordion title="Does PowerSync re-sync all data after client parameters are changed with overlapping buckets?" defaultOpen={false}>
83+
PowerSync will only sync the difference (buckets added or removed).
6884
</Accordion>
69-
</AccordionGroup>
85+
</AccordionGroup>

0 commit comments

Comments
 (0)