It is partially expanded out into columns to potentially allow filtering etc., but the interface of the class is still exactly the same as before. This allows to fully reconsstruct the edit history of the database, except in the case of batch transactions like the GEDCOM import below, which is not linked to any traceable commits (`first` and `last` are `NULL`):įinally, the actual commit data that was previously held by `undodb` is in the `commits` table.

This is essentially the data stored in `undoq`, but persisted to the database, with one important addition: it also adds a row for any undo/redo transaction. The second table is called 'transactions' and contains one row for every transaction. It only adds a row if the session edits the database (if transactions/commits are done). The first table is called 'sessions' and just adds an ID and a timestamp for each new session. for Web API, where each HTTP request opens a new 'session'. It is implemented in a way that even simultaneous sessions would record their transactions and commits in a consistent way. Instead of just a single table of commits, there are actually three tables to allow storing the history from multiple 'sessions' (opening and closing the application). The steps outlined above are not modified, but the `undodb` list is removed and the list-like interface of `DbGenericUndo` is instead implemented by a SQLite table in a new database `undo.db` (the constant for this filename was already present in the API of the class, but unused, so it looks like this was already foreseen). When a transaction is redone, it is moved again from the `redoq` to the `undoq` and the commits in `undodb` are applied again in the original order. When a transaction is undone, the transaction is moved from the `undoq` to the `redoq` and the commits (identified by two integers `first` and `last` in the transaction) are applied inversely and in opposite order to the database. When a transaction is commited to the database, the transaction object (`DbTxn`) is appended to `undoq` and the commits (1 or more) are appended to the `undodb` list.

That way, no other parts of the codebase need to be modified as the interface of the class stays the same.Īn instance of `DbGenericUndo` has the properties `undoq` (of type `que`), `redoq` and `undodb` (of type list). Triggered by the discussion in … ssues/320, I implemented an SQLite-based undo log by simply modifying the existing methods of `.DbGenericUndo`.

Good question, it definitely should, but thinking about your question I realized we are still missing some features. The cheapest option is to self-host on a Raspberry Pi (this is what I am doing), but it’s only for advanced users.Īnd will it be possible to migrate to it from the current version when it arrives? I would guess 2-3 months.īy the way, comparing to Ancestry - a hosted Gramps Web will not be free either as hosting costs money, but it should be significantly cheaper than self-hosting an individual instance like on DigitalOcean that costs at least 6 $/month. The first version of multi-tenant support will actually be released this week, but it’s difficult to predict how long it will take until there is a reliable hosted version for users to sign up.

When do you anticipate the hosted version will be available Sharing is a deal-breaker for me as this is a family project. The ambition of Gramps Web is to serve users who would like the convenience of online tree sharing and collaboration of tools like Ancestry, but want to retain full control, use open source tools, and have excellent integration with the best open source desktop app.

Is gramps a good family tree maker