Documentation edits made through Mintlify web editor

Author: benitav

usage/lifecycle-maintenance/implementing-schema-changes.mdx

@@ -6,13 +6,14 @@ title: "Implementing Schema Changes"
 
 The [PowerSync protocol](/architecture/powersync-protocol) is schemaless, and not directly affected by schema changes.
 
-Replicating data from the source database to [sync buckets](/usage/sync-rules) may be affected by server-side changes to the schema (in the case of Postgres), and may need reprocessing in some cases.
+Replicating data from the source database to [sync buckets](/usage/sync-rules) may be affected by server-side changes to the schema (in the case of Postgres), and may need [reprocessing](/usage/lifecycle-maintenance/compacting-buckets) in some cases.
 
 The [client-side schema](/installation/client-side-setup/define-your-schema) is just a view on top of the schemaless data. Updating this client-side schema is immediate when the new version of the app runs, with no client-side migrations required.
 
 The developer is responsible for keeping client-side schema changes backwards-compatible with older versions of client apps. PowerSync has some functionality to assist with this:
 
 1. [Different Sync Rules](/usage/sync-rules/advanced-topics/multiple-client-versions) can be applied based on [parameters](/usage/sync-rules/advanced-topics/client-parameters) such as client version.
+
 2. Sync Rules can apply simple [data transformations](/usage/sync-rules/data-queries) to keep data in a format compatible with older clients.
 
 ## Client-Side Impact of Schema and Sync Rule Changes
@@ -22,28 +23,39 @@ As mentioned above, the PowerSync system itself is schemaless — the client syn
 The schema as supplied on the client is only a view on top of the schemaless data.
 
 1. If tables/collections not described by the client-side schema are synced, it is stored internally, but not accessible.
+
 2. Same applies for columns/field not described by the client-side schema.
+
 3. When there is a type mismatch, SQLite's `CAST` functionality is used to cast to the type described by the schema.
+
    1. Data is internally stored as JSON.
+
    2. SQLite's `CAST` is used to cast values to `TEXT`, `INTEGER` or `REAL`.
+
    3. Casting between types should never error, but it may not fully represent the original data. For example, casting an arbitrary string to `INTEGER` will likely result in a "0" value.
+
    4. Full rules for casting between types are described [in the SQLite documentation here](https://www.sqlite.org/lang%5Fexpr.html#castexpr).
+
 4. Removing a table/collection is handled on the client as if the table exists with no data.
+
 5. Removing a column/field is handled on the client as if the values are `undefined`.
 
 Nothing in PowerSync will fail hard if there are incompatible schema changes. But depending on how the app uses the data, app logic may break. For example, removing a table/collection that the app actively uses may break workflows in the app.
 
 To avoid certain types of breaking changes on older clients, Sync Rule [transformations](/usage/sync-rules/data-queries) may be used.
 
-## <Icon icon="elephant" iconType="solid" size="24"/> Postgres Specifics
+## <Icon icon="elephant" iconType="solid" size="24" /> Postgres Specifics
 
 PowerSync keeps the [sync buckets](/usage/sync-rules/organize-data-into-buckets) up to date with any incremental data changes, as recorded in the Postgres [WAL](https://www.postgresql.org/docs/8.0/wal.html) / received in the logical replication stream. This is also referred to as DML (Data Manipulation Language) queries.
 
 However, this does not include DDL (Data Definition Language), which includes:
 
 1. Creating, dropping or renaming tables.
+
 2. Changing replica identity of a table.
+
 3. Adding, dropping or renaming columns.
+
 4. Changing the type of a column.
 
 ### Postgres schema changes affecting Sync Rules
@@ -58,7 +70,7 @@ The new table is detected as soon as data is inserted.
 
 #### DROP and re-CREATE table
 
-This is a special case of combining `DROP` and `CREATE`. If a dropped table is created again, _and_ data is inserted into the new table, the schema change is detected by PowerSync. PowerSync will delete the old data in this case, as if `TRUNCATE` was called before dropping.
+This is a special case of combining `DROP` and `CREATE`. If a dropped table is created again, *and* data is inserted into the new table, the schema change is detected by PowerSync. PowerSync will delete the old data in this case, as if `TRUNCATE` was called before dropping.
 
 #### RENAME table
 
@@ -73,13 +85,17 @@ This may be a slow operation if the table is large, and all other replication wi
 The replica identity of a table is considered changed if either:
 
 1. The type of replica identity changes (`DEFAULT`, `INDEX`, `FULL`, `NOTHING`).
+
 2. The name or type of columns part of the replica identity changes.
 
 The latter can happen if:
 
 1. Using `REPLICA IDENTITY FULL`, and any column is added, removed, renamed, or the type changed.
+
 2. Using `REPLICA IDENTITY DEFAULT`, and the type of any column in the primary key is changed.
+
 3. Using `REPLICA IDENTITY INDEX`, and the type of any column in the replica index is changed.
+
 4. The primary key or replica index is removed or changed.
 
 When the replica identity changes, the entire table is re-replicated again. This may be a slow operation if the table is large, and all other replication will be blocked until the table is replicated again.
@@ -107,21 +123,22 @@ If a table is added to the publication, it is treated the same as a new table, a
 There are additional changes that can be made to a table in a publication:
 
 1. Which operations are replicated (insert, update, delete and truncate).
+
 2. Which rows are replicated (row filters).
 
 Those changes are not automatically picked up by PowerSync during replication, and can cause PowerSync to miss changes if the changes are filtered out. PowerSync will not automatically recover the data when for example removing a row filter. Use these with caution.
 
-## <Icon icon="leaf" iconType="solid" size="24"/> MongoDB (Alpha) Specifics
+## <Icon icon="leaf" iconType="solid" size="24" /> MongoDB (Alpha) Specifics
 
 <Info>
-   This section is a work in progress. More details for MongoDB connections are coming soon. In the meantime, check our [MongoDB guide](/migration-guides/mongodb-atlas) to try out our MongoDB alpha support, and ask on our [Discord server](https://discord.gg/powersync) if you have any questions.
+  This section is a work in progress. More details for MongoDB connections are coming soon. In the meantime, check our [MongoDB guide](/migration-guides/mongodb-atlas) to try out our MongoDB alpha support, and ask on our [Discord server](https://discord.gg/powersync) if you have any questions.
 </Info>
 
 Since MongoDB is generally schemaless, there are generally no schema changes that impact PowerSync.
 
 However, dropping and renaming collections in MongoDB needs to be taken into consideration. More details on this will be documented soon.
 
-## <Icon icon="dolphin" iconType="solid" size="24"/> MySQL (Alpha) Specifics
+## <Icon icon="dolphin" iconType="solid" size="24" /> MySQL (Alpha) Specifics
 
 <Info>
   This section is a work in progress. More details for MySQL connections are coming soon. In the meantime, ask on our [Discord server](https://discord.gg/powersync) if you have any questions.
@@ -130,4 +147,5 @@ However, dropping and renaming collections in MongoDB needs to be taken into con
 ## See Also
 
 * [Custom Types, Arrays and JSON](/usage/use-case-examples/custom-types-arrays-and-json)
-* [Deploying Schema Changes](/usage/lifecycle-maintenance/deploying-schema-changes)
+
+* [Deploying Schema Changes](/usage/lifecycle-maintenance/deploying-schema-changes)