| Filename | Latest commit message | Latest commit date |
|---|---|---|
Tizian 「ティツィアーン」
9495f616c4
A merge that touched any foreign key ran the planning pass for its new rows and then the full projection pass, whose closure follows foreign keys both ways and so loads every row connected to the merged ones. In a library whose tags join its parts, one merged rating, edit, tag or new card loaded all of it: about 9.5 s on a device receiving it and 12 s on the server merging a push, for 8,000 cards. A batch that only inserts new rows (each once) and updates columns no projection reads now leaves both passes out when its inserts are proven, as local inserts are (canLeaveProjectionUnchangedByMergedInserts, on localProjectionDependenciesAreStable): each row references its parents by id, each parent visible or inserted earlier in the same batch, nothing refers to the row yet (no row, no attempted value), and no unique claim is contested. A parent inserted after its child in the batch would find the child's reference held back, which only the pass restores, so it counts only when earlier. Deletes, inserts onto rows there already and anything unproven take the passes as before. The batch's parents are still resolved together for the writes. The new tests cover a child of a visible parent, a parent and child in one batch (both through the shortcut), and a child of a merged delete and a parent arriving after its held-back child (both through the passes); dropping the parent or the reference check fails the matching test. The core, server, integration and simulation suites pass, but for two PostgreSQL tests that cannot start their database while another embedded PostgreSQL runs, with or without this change. 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