| Filename | Latest commit message | Latest commit date |
|---|---|---|
Tizian 「ティツィアーン」
741e334d6a
Collecting pending changes read each change's domain row on its own: one statement per insert, and one per update for the column it carries. A device that had never synced a space of about 100,600 field rows made the server run some 60,000 of them in the collection's one transaction, 143 to 198 s, and since nothing is sent before everything is collected, the client's connection closed first and the next attempt started over. Before walking the inserts, and again before walking the updates, the collection now reads the rows they name ahead, 500 to a statement per table and space, with the same column expressions, in the same snapshot: SELECT those columns WHERE "spaceId" = the space AND "id" IN (the rows). The raw rows are kept for the collection and each found row's owner is recorded in the owner cache; an insert decodes its row and restores its attempted values from them as before, and an update takes its column from them, so the updates of a row collected as an insert read nothing more. A row the read-ahead didn't find (missing, or owned by another space) takes the per-row path unchanged, which tells those cases apart; both end the collection with an integrity violation, so they are left unbatched. Deletes still look up their owners row by row, but find in the owner cache every row the same collection read ahead. Chunking and streaming are unchanged. Measured on embedded PostgreSQL, a first collection of 30,040 rows and 90,054 updates (90,067 field rows) took 51.5 to 53.6 s before and takes 16.9 to 17.1 s now, its 120,194 changes identical on the wire, byte for byte, to what the per-row path produces from the same database. On SQLite, 3,594 changes of a fixture with structured columns, blobs, deletes and attempted foreign keys on inserts and updates are byte for byte the same before and after. The new test collects 1,200 rows, 600 of them renamed, for a fresh peer (1,800 reads of the table before, 3 now), and 600 renames since a peer's checkpoint (600 reads before, 2 now), and checks every payload against the author's rows and the peer's rows after the merge. The core, server, integration and simulation suites pass, but for one cross-space seed with delta delivery (DST_SEED_BASE=1794152224), whose local update of an organization finds no row before this change as after. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me> |
||
| .. | ||
| .test_databases | ||
| bin | ||
| config | ||
| lib | ||
| migrations | ||
| test | ||
| .gitignore | ||
| analysis_options.yaml | ||
| CHANGELOG.md | ||
| dart_test.yaml | ||
| pubspec.yaml | ||
| README.md | ||
serverpod_offline_sync_test_server
This is the starting point for your Serverpod server.
To run your server, you first need to start Postgres and Redis. It's easiest to do with Docker.
docker compose up --build --detach
Then you can start the Serverpod server.
dart bin/main.dart
When you are finished, you can shut down Serverpod with Ctrl-C, then stop Postgres and Redis.
docker compose stop