Skip to main content

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.
To illustrate this, we will use the React To-Do List demo app and modify it to use UUIDs on the client and map them to sequential IDs on the backend source database (Supabase in this case).

Overview

Before we get started, let’s outline the changes we will have to make:
1

Schema

Update the lists and todos tables
2

Create SQL triggers

Add two triggers that will map the UUID to the integer ID and vice versa.
3

Update Sync Streams

Update your Sync Streams (or legacy Sync Rules) to use the UUID column instead of the integer ID.
4

Update client to use UUIDs.

The following components/files will have to be updated:
  • Files:
    • AppSchema.ts
    • fts_setup.ts
    • SupabaseConnector.ts
  • Components:
    • lists.tsx
    • page.tsx
    • SearchBarWidget.tsx
    • TodoListsWidget.tsx

Schema

In order to map the UUID to the integer ID, we need to update the
  • lists table by adding a uuid column, which will be the secondary ID, and
  • todos table by adding a uuid column, and a list_uuid foreign key column which references the uuid column in the lists table.
With the schema updated, we now need a method to sync and map the 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 between list_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:
  1. update_integer_id, and
  2. update_uuid_column

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

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
We now have triggers in place that will handle the mapping for our updated schema and can move on to updating your Sync Streams/Sync Rules to use the UUID column instead of the integer ID.

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 the uuid 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.
We can now move on to updating the client to use UUIDs.

Update Client to Use UUIDs

With Sync Streams updated, we no longer have the list_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
The 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