From d53408c7a7b701d44ca9e9f26c3c567e88d321a0 Mon Sep 17 00:00:00 2001 From: James Arthur Date: Thu, 28 Sep 2023 10:47:46 +0200 Subject: [PATCH] docs: clarify primary key uniqueness requirement. (#503) Not globally unique across tables. --- docs/reference/roadmap.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/reference/roadmap.md b/docs/reference/roadmap.md index 4c7a1ced98..011cc114bf 100644 --- a/docs/reference/roadmap.md +++ b/docs/reference/roadmap.md @@ -89,11 +89,11 @@ By understanding and acknowledging these constraints, you can leverage ElectricS ### Uniqueness constraints -#### Primary keys need to be globally unique +#### Primary keys need to be unique -In centralised databases, the creation of two rows with the same primary key causes one of the transactions to abort. In local-first applications, that conflict would only be detected after-the-fact, leaving the state of clients unreconcilable. In ElectricSQL, we require that each key can only be created by a single client at any point in time, ensuring that primary keys are globally unique. +In centralised databases, the creation of two rows with the same primary key causes one of the transactions to abort. In local-first applications, that conflict would only be detected after-the-fact, leaving the state of clients unreconcilable. In ElectricSQL, we require that each key can only be created by a single client at any point in time, ensuring that primary keys are unique (to their table -- rows in different tables can have the same primary key value). -To ensure that primary keys are globally unique, you can use: +To ensure that primary keys are unique, you can use: - UUIDs are typically a safe approach (be aware of limitation with some browsers and devices [REF]) - Unique data about the client for generating the value safely. E.g., use the clientId in a composed primary-key.