zeldafreak
commented
7 months ago Just wanted to call out that this feature might be complicated by https://github.com/jinaga/jinaga.net/issues/93.
Imagine that users perform some workflow offline, and facts are added locally to persist the intermediate state of that workflow. At the end of the workflow, the final product is put in the outgoing queue to be persisted to the replicator.
Part of the point of the rollover would be to delete these local facts, but Jinaga would have no way of knowing the difference between intermediate facts that were created as part of a completed workflow (and thus the final product was placed in the outgoing queue) vs intermediate facts whose workflow has not yet completed. In both situations, the outgoing queue would be empty.
I think it's OK to leave this problem to the developer and document that the method shouldn't be called unless you're certain there's nothing stored locally that is still needed. Or it could be documented that immediately after performing a rollover, you should perform local queries that will pull all those relevant, locally-stored facts from the secondary database, in which case we should be sure that the "local" Jinaga client will query the background database.
Provide a method that the application can call periodically. When called, the Jinaga client should move the current SQLite database into the background and create a new database for the foreground. If there is already a background database and it has an empty outgoing queue, delete it. If the outgoing queue is not empty, fail the operation. Pull facts form the background database to satisfy any specification and store them in the foreground database.