b22b29679b
* Pre: remove remnants of 'open_empty' * Pre: Cleanup 'datoms' table after a timeline move Since timeline move operations use a transactor, they generate a "phantom" 'tx' and a 'txInstant' assertion. It is "phantom" in a sense that it was never present in the 'transactions' table, and is entirely synthetic as far as our database is concerned. It's an implementational artifact, and we were not cleaning it up. It becomes a problem when we start inserting transactions after a move. Once the transactor clashes with the phantom 'tx', it will retract the phantom 'txInstant' value, leaving the transactions log in an incorrect state. This patch adds a test for this scenario and elects the easy way out: simply remove the offending 'txInstant' datom. * Part 1: Sync without support for side-effects A "side-effect" is defined here as a mutation of a remote state as part of the sync. If, during a sync we determine that a remote state needs to be changed, bail out. This generally supports different variations of "baton-passing" syncing, where clients will succeed syncing if each change is non-conflicting. * Part 2: Support basic "side-effects" syncing This patch introduces a concept of a follow-up sync. If a sync generated a "merge transaction" (a regular transaction that contains assertions necessary for local and remote transaction logs to converge), then this transaction needs to be uploaded in a follow-up sync. Generated SyncReport indicates if a follow-up sync is required. Follow-up sync itself is just a regular sync. If remote state did not change, it will result in a simple RemoteFastForward. Otherwise, we'll continue merging and requesting a follow-up. Schema alterations are explicitly not supported. As local transactions are rebased on top of remote, following changes happen: - entids are changed into tempids, letting transactor upsert :db/unique values - entids for retractions are changed into lookup-refs if we're confident they'll succeed -- otherwise, retractions are dropped on the floor * Post: use a macro for more readable tests * Tolstoy README |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
Development flow for Mentat FFI
Android SDK
Android Mentat SDK is one of two first-party consumers (the other one being iOS Mentat SDK).
Binaries produced by cargo build ... are symlinked from within the SDK, and a number of target-specific libmentat_ffi.so binaries are bundled together and distributed with the SDK.
There is a build script at <mentat_root>/scripts/android_build.sh which knows how to cross-compile mentat_ffi for various Android targets.
./<mentat_root>/scripts/android_build.sh- compiles for all supported targets./<mentat_root>/scripts/android_build.sh x86- compiles forx86./<mentat_root>/scripts/android_build.sh x86 arm- compiles forx86,arm
General development flow while working on the Android SDK is:
- (pre) compile for all targets, if you've never done so
- make changes to
mentat_ffiand/ormentat - re-compile
mentat_ffibinaries using./android_build.sh x86. During development it's faster to compile just for the target which matches your emulator, e.g.x86 - make corresponding changes in the Android SDK, try them out from within the bundled sample project
- since binaries are symlinked, no manual copy step is necessary for the Android SDK to pick up the changes
iOS SDK
TODO, contribute via issue #732.