| Filename | Latest commit message | Latest commit date |
|---|---|---|
Tizian 「ティツィアーン」
012d94d0ca
A merge that deleted anything ran the full projection pass, whose closure follows foreign keys both ways and so loads every row connected to the deleted ones. A device deleting a card with its revisions, tags and reviews cost each device receiving it about 4 s, and the server merging the push about 5.4 s, in a library of 8,000 cards whose tags join it. A device deleting a row locally tombstones everything visible below it, so its batch carries those deletes along. What the pass could still decide is a row below that the deleting device never saw, inserted here meanwhile, which it hides by cascade. A batch that only deletes (none restoring) now leaves the pass out when the deleted tables cascade only, by the same rules as a local delete (_deletesOnlyCascade, shared with canSkipProjectionAfterLocalDelete now), no attempted value is pending in the connected tables, and every visible row below a deleted one, found by walking down the cascades alone, is deleted by the same batch (canLeaveProjectionUnchangedByMergedDeletes). A batch both inserting and deleting, or restoring, takes the pass as before. Measured on PostgreSQL: such a card delete merges in about 35 ms instead of 5.4 s; received on a device, 99 ms instead of 4 s. The new tests cover a leaf deleted through the shortcut and a middle row's delete, which isn't eligible, hiding its children by the pass; in the app's sync tests a card deleted while another device rated it declines the shortcut, and dropping the walk's check fails that test. The core, server, integration and simulation suites pass, but for two PostgreSQL tests that can't start their database while another embedded PostgreSQL runs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
| .. | ||
| .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