Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| @@ -0,0 +1,40 @@ | |||
| {/* Shared body: rendered by sync/advanced/case-sensitivity.mdx (Sync Streams section) and sync/rules/case-sensitivity.mdx (Sync Rules (Legacy) section). Keep the content valid for both engines. */} | |||
|
|
|||
| ### Case in Sync Rules | |||
There was a problem hiding this comment.
This snippet now renders on the Sync Streams page (sync/advanced/case-sensitivity.mdx) as well as the Sync Rules page, but the heading and prose still frame case-folding as a Sync Rules-only behavior: "Case in Sync Rules" here, "Sync Rule queries" on line 5, "case produced by Sync Rules" on line 15, and "this Sync Rule query" on line 28. A Sync Streams reader will see this unchanged and be pointed at a concept ("Sync Rules") that doesn't apply to them. Reword these to be engine-neutral (e.g. "Case in Sync Queries" / "sync queries") so the shared body actually reads as valid for both engines.
| - Postgres, MySQL and SQL Server: use a UUID for `id`. Use the `uuid()` helper to generate a random UUID (v4) on the client. | ||
| - MongoDB: use an `ObjectId` for `_id`. Generate an `ObjectId()` in your app code and store it in the client's `id` column as a string; this will map to MongoDB's `_id`. | ||
|
|
||
| To use a different column/field from the server-side database as the record ID on the client, use a column/field alias in your [Sync Streams](/sync/streams/overview) query (or [Sync Rules](/sync/rules/overview) data query): |
There was a problem hiding this comment.
This shared snippet renders on the Sync Streams page too, so the "(or Sync Rules data query)" aside puts Sync Rules content side by side with Sync Streams content on the Sync Streams page. The Note on line 15 has the same "...queries and Sync Rules ... data queries..." pairing. Drop the Sync Rules pointer here (state the Sync Streams query alias only) and split out the Sync Rules-specific phrasing into the Sync Rules wrapper page instead, or make both lines engine-neutral if the behavior is identical.
|
|
||
| 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). |
There was a problem hiding this comment.
"...in your [Sync Streams] or [Sync Rules]" pairs both engines side by side in a snippet that now also renders on the Sync Streams wrapper page. Line 44 has the same pattern. Since this snippet is shared, state the connection-tag behavior once without naming both engines (e.g. "distinguished by connection tag in your sync definitions"), rather than listing "Sync Streams or Sync Rules" each time.
|
|
||
| You should not add multiple connections to multiple replicas of the same database — this would cause data duplication. Only use this when the data on each connection does not overlap. | ||
|
|
||
| It will be possible for each connection to be configured with a "tag", to distinguish these connections in Sync Rules. The same tag may be used for multiple connections (if the schema is the same in each). |
There was a problem hiding this comment.
This planned-feature description says connections will be distinguished "in Sync Rules" only, but this snippet also renders on the Sync Streams page, and the equivalent description in sharded-databases.mdx describes the same tag as applying to "Sync Streams or Sync Rules." Update this to cover both engines (or use engine-neutral wording) so it doesn't read as Sync Rules-only when shown on the Sync Streams wrapper.
1 participant
Stacked on #640, merge that one first.
Sync Rules are deprecated, so this PR separates the two engines in the docs. The Sync Streams section reads as if Sync Rules never existed, and the Sync Rules (Legacy) section has everything a Sync Rules user still needs while they migrate.
sync/rules/. Sync Streams pages no longer mention Sync Rules anywhere.pnpm check:links) now understands headings that live in snippets..claude/are updated: new docs cover Sync Streams, Sync Rules docs stay accurate without being prioritized, and the two are never shown side by side.Worth a look on the preview: the shared pages in both sections (two of them import a nested snippet), and sidebar highlighting on those pages.
🤖 Generated with Claude Code