Sequential ID Mapping
In this tutorial we will show you how to map a local UUID to a remote sequential (auto-incrementing) ID.
Introduction
When auto-incrementing / sequential IDs are used on the backend database, the ID can only be generated on the backend database, and not on the client while offline. To handle this, you can use a secondary UUID on the client, then map them to a sequential ID when performing an update on the backend 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 database (Supabase in this case).
Overview
Before we get started, let’s outline the changes we will have to make:
Schema
Update the lists
and todos
tables
Create SQL triggers
Add two triggers that will map the UUID to the integer ID and vice versa.
Update Sync Rules
Update the Sync Rules to use the new integer ID instead of the UUID column.
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 auuid
column, which will be the secondary ID, andtodos
table by adding auuid
column, and alist_uuid
foreign key column which references theuuid
column in thelists
table.
With the schema updated, we now need a method to synchronize 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 synchronized 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
We now have triggers in place that will handle the mapping for our updated schema and can move on to updating the Sync Rules to use the UUID column instead of the integer ID.
Update Sync Rules
As sequential IDs can only be created on the backend database, we need to use UUIDs in the client. This can be done by updating both the parameters
and data
queries to use the new uuid
columns.
The parameters
query is updated by removing the list_id
alias (this is removed to avoid any confusion between the list_id
column in the todos
table), and
the data
query is updated to use the uuid
column as the id
column for the lists
and todos
tables. We also explicitly define which columns to select, as list_id
is no longer required in the client.
With the Sync Rules updated, we can now move on to updating the client to use UUIDs.
Update Client to Use UUIDs
With our Sync Rules 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.
The uploadData
function in SupabaseConnector.ts
needs to be updated to use the new uuid
column in both tables.
For the remaining files, we simply need to replace any reference to list_id
with list_uuid
.
Was this page helpful?