Introduction
When auto-incrementing / sequential IDs are used on the backend source database, the ID can only be generated on the backend source database, and not on the client while offline. To handle this, you can use a secondary UUID on the client, then map it to a sequential ID when performing an update on the backend source database. This allows using a sequential primary key for each record, with a UUID as a secondary ID.This mapping must be performed wherever the UUIDs are referenced, including for every foreign key column.
Overview
Before we get started, let’s outline the changes we will have to make:Update Sync Streams
Update your Sync Streams (or legacy Sync Rules) to use the UUID column instead of the integer ID.
Schema
In order to map the UUID to the integer ID, we need to update theliststable by adding auuidcolumn, which will be the secondary ID, andtodostable by adding auuidcolumn, and alist_uuidforeign key column which references theuuidcolumn in theliststable.
list_id and list_uuid in the todos table, with the id and uuid columns in the lists table.
We can achieve this by creating SQL triggers.
Create SQL Triggers
We need to create triggers that can look up the integer ID for the given UUID and vice versa. These triggers will maintain consistency betweenlist_id and list_uuid in the todos table by ensuring that they remain in sync with the id and uuid columns in the lists table;
even if changes are made to either field.
We will create the following two triggers that cover either scenario of updating the list_id or list_uuid in the todos table:
update_integer_id, andupdate_uuid_column
Trigger 1: update_integer_id
Trigger 1: update_integer_id
The
update_integer_id trigger ensures that whenever a list_uuid value is inserted or updated in the todos table,
the corresponding list_id is fetched from the lists table and updated automatically. It also validates that the list_uuid exists in the lists table; otherwise, it raises an exception.Trigger 2: update_uuid_column
Trigger 2: update_uuid_column
The
update_uuid_column trigger ensures that whenever a list_id value is inserted or updated in the todos table, the corresponding list_uuid is fetched from the
lists table and updated automatically. It also validates that the list_id exists in the lists table.update_uuid_column
Update Sync Streams
As sequential IDs can only be created on the backend source database, we need to use UUIDs in the client. The sync config is updated to use theuuid column as the id column for the lists and todos tables, explicitly defining which columns to select so that list_id (the integer ID) is no longer exposed to the client.
- Sync Streams
- Sync Rules (Legacy)
Update Client to Use UUIDs
With Sync Streams updated, we no longer have thelist_id column in the todos table.
We start by updating AppSchema.ts and replacing list_id with list_uuid in the todos table.
AppSchema.ts
uploadData function in SupabaseConnector.ts needs to be updated to use the new uuid column in both tables.
SupabaseConnector.ts
For the remaining files, we simply need to replace any reference to
list_id with list_uuid.fts_setup.ts
page.tsx
TodoListWidget.tsx
SearchBarWidget.tsx