You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While a local migration is pending upload, `cloudsync_network_send_changes()`
66
-
returns an error instead of sending row changes. This prevents data produced
67
-
with a new local schema from reaching a server that has not accepted that schema.
66
+
If a pending migration upload fails, row changes are not sent. This prevents
67
+
data produced with a new local schema from reaching a server that has not
68
+
accepted that schema.
69
+
70
+
## Initial Schema Sync
71
+
72
+
The first version of a database is distributed with the same migration protocol
73
+
used for later schema changes. There is no separate bootstrap format.
74
+
75
+
Client-to-cloud first sync:
76
+
77
+
1. The client must have `database_id` configured and must sync with an API key
78
+
that is allowed to initiate schema migrations.
79
+
2. The app defines the first schema with `cloudsync_alter_create_table()`,
80
+
`cloudsync_alter_add_column()`, `cloudsync_alter_augment_table()`, and any
81
+
optional commands such as `cloudsync_alter_set_block_lww()`.
82
+
3.`cloudsync_alter_apply()` creates the local tables, records the schema epoch,
83
+
and stores a pending upload in `cloudsync_pending_migration`.
84
+
4. The app may insert initial data.
85
+
5.`cloudsync_network_sync()` uploads the pending schema migration first. The
86
+
backend applies it to the cloud database, records it in the per-`database_id`
87
+
schema log, and only then can row data be uploaded.
88
+
89
+
Cloud-to-client first sync:
90
+
91
+
1. The backend applies and records the initial migration for the `database_id`.
92
+
2. A new SQLite client only needs `database_id` and a valid API key.
93
+
3.`cloudsync_network_sync()` detects that the local database has no augmented
94
+
tables, calls the schema check endpoint, applies the first migration locally,
95
+
and then continues with normal row download.
96
+
97
+
An empty client that has no local schema and no server-side migration simply
98
+
returns an empty sync result.
68
99
69
100
## Declarative API
70
101
@@ -259,7 +290,7 @@ Client-originated migration:
259
290
1. Application queues operations with `cloudsync_alter_*`.
260
291
2. Application calls `cloudsync_alter_apply()`.
261
292
3. Extension applies the migration locally and writes `cloudsync_pending_migration`.
262
-
4.Application or `cloudsync_network_sync()` uploads the pending migration.
293
+
4.`cloudsync_network_sync()` uploads the pending migration before row changes; applications may call `cloudsync_network_migration_upload()` explicitly when they want a separate schema publish step.
263
294
5. Backend authorizes the API key, applies the payload to the cloud database,
264
295
records the migration, and returns success.
265
296
6. Client sends row changes after the pending migration is uploaded.
@@ -286,7 +317,7 @@ Empty client first sync:
286
317
- A migration id is idempotent through `cloudsync_migrations`.
287
318
- Explicit hash guards are enforced when present.
288
319
- Raw SQL runs inside the same savepoint as portable operations.
289
-
- Row changes are not uploaded while `cloudsync_pending_migration` contains an unuploaded migration.
320
+
- Row changes are uploaded only after all pending local schema migrations have been accepted by the backend.
290
321
- V2 migrations should be blocked by the backend when stale/offline clients may still upload incompatible old-epoch payloads, unless the backend has an explicit rejection or translation policy.
`cloudsync_alter_preview()` can be used before `cloudsync_alter_apply()` to inspect the generated payload. After apply, the payload is saved in `cloudsync_pending_migration`; `cloudsync_network_migration_upload()` uploads the next pending migration and marks it uploaded on success.
27
+
`cloudsync_alter_preview()` can be used before `cloudsync_alter_apply()` to inspect the generated payload. After apply, the payload is saved in `cloudsync_pending_migration`; `cloudsync_network_sync()` uploads pending migrations before it sends row changes. `cloudsync_network_migration_upload()` is still available when schema should be published separately from data.
29
28
30
29
The backend should authorize the API key, apply the payload to the cloud database, append it to the schema migration log for the `database_id`, and distribute it to other clients through `schema/check` or `schema/download`.
31
30
32
31
`client-to-server.sql` contains the same flow as an executable SQLite example. `client-to-server-v1.json` is the manual JSON equivalent for backend tests or custom tooling; application code should normally let `cloudsync_alter_apply()` generate that payload.
33
32
33
+
## Initial Database Sync
34
+
35
+
The first version of a database uses the same flow. A schema-capable client
36
+
queues the first `createTable` migration, calls `cloudsync_alter_apply()`,
37
+
optionally inserts initial rows, and then calls `cloudsync_network_sync()`.
38
+
The schema upload is accepted by the backend before any row payload is sent.
39
+
40
+
For cloud-to-client bootstrap, the backend records the initial migration first.
41
+
A new SQLite client with only `database_id` and an API key calls
42
+
`cloudsync_network_sync()`; the client downloads the first schema migration,
43
+
creates/augments the tables, and then downloads data normally.
44
+
34
45
## Server-Originated V2 Migration
35
46
36
47
The backend applies and records a payload such as `server-to-client-v2.json`, then a client can update itself before receiving data:
0 commit comments