| Filename | Latest commit message | Latest commit date |
|---|---|---|
Tizian 「ティツィアーン」
b5450353b9
insteadOfDelete ran the full foreign key projection after every local delete. Its closure follows edges both ways, so it loads every row connected to the deleted one, which in a schema whose tables all hang off one another is nearly the whole database: one deleted row of a person's 8,000 flashcards loaded 56,000 of 56,350 CRDT rows and took about 8 s on the calling isolate, most of it deserialising rows. Inserts and updates have had a proof that the pass is unnecessary (canLeaveLocalProjectionUnchanged); deletes had none. canSkipProjectionAfterLocalDelete proves it for a delete: every table the delete can cascade into is reached by cascade edges on id only, none of them restricts its parent (a deleted child can release a parent delete held back by it), none has a unique index (a released claim can bring a contestant back) or lies in a component with a SET DEFAULT edge, and no attempted value is pending in the connected tables. The delete's own cascade (applyDeleteActions) then is the whole projection; otherwise the full pass runs as before. applyDeleteActions also asks for the visible children of a whole batch of parents at once for cascades by id, instead of one query per parent. On that database a single delete now takes 6-63 ms, a card with its revisions, tags and reviews 46-145 ms instead of 28-39 s. The new tests cover a restrict child deleted locally releasing a merged parent delete (on the person tables, and on the chain tables, where the shortcut is asked and declines: the test fails with the restrict condition removed) and a cascade child deleted locally through the shortcut, its parent then deleted by a merged remote delete. The core, server, integration and simulation suites pass. 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