Add guide for time-based sync workarounds #328
Conversation
khawarizmus
requested review from
benitav,
kobiebotha,
michaelbarnes and
rkistner
|
|
||
| # The Problem | ||
|
|
||
| Sync rules only support a limited set of operators when filtering on parameters. You can use `=`, `IN`, and `IS NULL`, but not range operators like `>`, `<`, `>=`, or `<=`. |
There was a problem hiding this comment.
I'd add a hyperlink to operators to https://docs.powersync.com/usage/sync-rules/operators-and-functions for more details
|
|
||
| This gives users full control over which dates to sync, with no schema changes or scheduled jobs required. | ||
|
|
||
| The trade-off is granularity. In this example we're using daily buckets. If you need finer precision (hourly), syncing a large range means many buckets. If you use larger buckets (monthly), you lose the ability to filter accurately. |
There was a problem hiding this comment.
syncing a large range means many buckets.
It would be good to add why many buckets are a problem. i.e. I assume the main consideration is the 1,000 bucket limit
| **Cons:** Requires schema changes and scheduled jobs (e.g., pg_cron). Limited to pre-defined time ranges. | ||
| </Warning> | ||
|
|
||
| If you need more flexibility like letting users pick arbitrary date ranges [see Workaround 2](#2:-buckets-per-date). |
There was a problem hiding this comment.
The links here feel a bit weird because they just link to the next line. Feels like we could just say "see the next workaround: Buckets Per Date" or similar
Co-authored-by: benitav <benitav@users.noreply.github.com>
Co-authored-by: benitav <benitav@users.noreply.github.com>
…of bucket granularity.
michaelbarnes
left a comment
michaelbarnes
left a comment
There was a problem hiding this comment.
Minor wording changes.
|
|
||
| # Workarounds | ||
|
|
||
| ## 1: Boolean Columns |
There was a problem hiding this comment.
Let's rather call this "Pre-defined time ranges".
| This approach works well when you have a small, fixed set of time ranges. However, it requires schema changes and a scheduled job to keep the columns updated. | ||
|
|
||
| <Warning> | ||
| **Cons:** Requires schema changes and scheduled jobs (e.g., pg_cron). Limited to pre-defined time ranges. |
There was a problem hiding this comment.
Remove the word "Cons", I think the Warning component highlights the "con" aspect of this approach.
| The trade-off is granularity. In this example we're using daily buckets. If you need finer precision (hourly), syncing a large range means many buckets, which can degrade sync performance and approach [PowerSync's limit of 1,000 buckets per user](https://docs.powersync.com/resources/performance-and-limits#performance-and-limits). If you use larger buckets (monthly), you lose the ability to filter accurately. | ||
|
|
||
| <Warning> | ||
| **Cons:** Must commit to a single granularity. Daily = too many buckets for long ranges. Monthly = lose precision for recent data. |
There was a problem hiding this comment.
Remove "Cons:". Similar to the previous comment.
Documents how to implement time-based filtering with current sync rule limitations.
Covers three workarounds:
Highlighted trade-offs for each