While the game is catching up, batch the "atomic transactions" done with the storage (i.e. not one every block but one every 1,000 blocks). This solves the issue described in #16, and makes Mover sync almost as fast with an on-disk SQLite file as with a database in memory.
The change also includes a refactoring commit that moves the transaction mechanism from GameLogic to StorageInterface, where it belongs logically. This allows us to take advantage of atomic transactions and the speed-up for SQLite databases directly in SQLiteStorage, rather than only for SQLiteGame's. Games with special external state can still use it as well, by having their own storage subclass that keeps both the libxayagame-related data and the game's external state data.
While the game is catching up, batch the "atomic transactions" done with the storage (i.e. not one every block but one every 1,000 blocks). This solves the issue described in #16, and makes Mover sync almost as fast with an on-disk SQLite file as with a database in memory.
The change also includes a refactoring commit that moves the transaction mechanism from
GameLogictoStorageInterface, where it belongs logically. This allows us to take advantage of atomic transactions and the speed-up for SQLite databases directly inSQLiteStorage, rather than only forSQLiteGame's. Games with special external state can still use it as well, by having their own storage subclass that keeps both thelibxayagame-related data and the game's external state data.