mORMot Open Source

RaelB

Member

Registered: 2010-08-04

Posts: 59

Moving from Desktop to Client/Server

Hi,
I'm used to developing desktop applications, where using an auto-incrementing integer is suitable/sufficient for ID fields. With client/server, this could work if you are always connected to the server, but practically one usually wants the app to also work in offline mode. I.e. add a number of records to the client, and then later sync with the server when one connects to it. So since mormot ID's are integer (and not GUID/string), what strategies can one or should one use, to handle this common scenario,
Thank you

RaelB

Member

Registered: 2010-08-04

Posts: 59

Re: Moving from Desktop to Client/Server

I asked ChatGPT, and it said:

What most mORMot users do

The two most common approaches are:

1️⃣ Negative temporary IDs (simplest)
2️⃣ GUID external key + integer DB key (most robust)

That makes sense. If you have any further experiences to share, that would also be helpful.

flydev

Member

From: France

Registered: 2020-11-27

Posts: 149

Website

Re: Moving from Desktop to Client/Server

Take a look there about using GUID as FK: https://github.com/synopse/mORMot2/issues/431

For your scenario, you want to study mormot SAD chapter 5.10 and ingesting 5.10.4. Replication use cases, then write programs for experimenting.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,416

Website

Re: Moving from Desktop to Client/Server

And do not forget about TSynUniqueIdentifier / TSynUniqueIdentifierGenerator which were meant to generate distributed safe Int64 IDs generation on client side, with no centralized server.

If each client has its own Process ID (e.g. a genuine value in the settings), it works just fine.

Of course, another option would be to put the logic on the server side, i.e. have the API make the integer ID generation.
This is the cleanest and the safest: put more on the server side, hidden behind the API, and less within the client.
But offline mode is not possible for this...

My advice is to not use UUID/GUID as identifiers because they are huge, and purely random, so never sorted.
Whereas ID sequences or TSynUniqueIdentifier are increasing in time, which is perfect for a BTree storage.
If you prefer big IDs, use rather TBsonObjectID.ComputeNew from mormot.db.nosql.bson.pas which are monotonic, and only 12 bytes / 96-bits.

Some people used pre-allocation of ID pools for offline usage.
It works well, but in practice, it tends to overcomplicate things.