> On Nov 8, 2018, at 8:50 AM, Craig Arno <cr...@arno.com> wrote: > > On 11/7/2018 1:42 PM, Craig Arno wrote: >> Using a queue has other benefits if you find yourself in a situation... > > For the "offline" update usecase where the primary database is "server" > based, a local SQLite database could be used for local offline work (travel > receipt entry), which the database Event Write Queue could be tee'd to a file > for later "online" update replay. > > When "online" status to the remote server based database is restored, the > "remote write queue" could be played to update the remote/server database. > This would have the net effect of "mirroring" the remote database > transactions locally for one user's offline work. > > In the read direction, a query for all database table entries between the > last successful update/connect and now will have to be performed and the > local database updated with new changes from User/Bookkeeper/Accountant > activity. If there are a "lot" of changes and online time is short or > connection speed slow, and potential for interruption high, it might be best > to queue up read database changes to disk until the database read "diff" is > complete for all tables. Then the "read" half of the Sync can then be > completed with local disk based "complete" diff data. And give the user a > little arrow chasing arrow button to do a "refresh" compare between local and > remote databases, if sync is ever in doubt. The "arrow chasing arrow button" > is consistent with how remote calendar/contact based office information > systems operate today. I do this with local machine Thunderbird Calendar and > my OwnCloud server based system.
That’s a lot more complex than any backend I’d want to implement, but fortunately GnuCash’s backends are plugins so you’re welcome to write a separate one. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
