Changes

Gramps 5.0 comes .x came with a new, alternative database backend called DB-API(Python Database API Specification). The Gramps 5.0.x default database will be remained the old standard Berkeley DB (often abbreviated as [[Gramps_Glossary#bsddb|BSDDB]]).

Testing with Gramps 5.0 is the initial test of .x showed the DB-API backend. If it works , worked well, then and with the release of Gramps 5.1 may make it .x the SQLite DB-API backend was made the default.

Gramps has been designed to work with two one DB-API SQL enginesengine:

* sqlite3 SQLite3 - single or multi-user on single operating system* [[DB-API_Database_Backend#Postgresql|postgresql]] - local or remote, single or multi-user

sqlite3 And experimental Addons have been provided for:* [[DB-API_Database_Backend#Postgresql|postgresql]] - local or remote, single(supported by Gramps) or multi-user(not possible with Gramps without a rewrite of the software.)* [[MongoDB]] - ?? SQLite3 has been tested the most and is the default SQL enginerecommended for use with the DB-API Database Backend. However, advanced users can adjust the details of the SQL connect. See [[#Advanced uses]] for more details.

# Users will just use DB-API with the default sqliteSQLite. Nothing will really be different from previous uses of BSDDB, but there is no lock file, and the data is much less likely to become corrupted. # Users can share their sqlite SQLite file on a single file system. Any user logged into that computer can work together on the same file. Operations like import will lock the file, but individual edits can be made simultaneously. Note: there is no code to prevent editing the same record at the same time. For sqliteSQLite, we would have to implement our own row-locking code. Or perhaps just give a warning if the data has changed since we started editing it.# Users can put their sqlite SQLite database on a file-sharing drive, like Dropbox, Google Drive, etc. This is tricky to understand. These systems are file-sharing, not record-sharing. That means that you can't have two users writing at the same time. In fact, if you have two users writing, you probably want to keep the session short. Start grampsGramps, make changes, exit. Or just browse. Or take turns.# Multiple users can use postgresql Postgresql locally. This is relatively speedy, but only really useful if the database is also made available over the network. Otherwise, you would probably just use sqliteSQLite.# Multiple users can use postgresql Postgresql remotely. This is the most powerful option, but also the slowest. Gramps is currently written in a manner that assumes a fast, local connection to the database. Over time, we can refine Gramps code to support this mode better, which will make the other uses faster as well. In any event, this mode should work well, once you have your large data loaded. All operations should work as normal.

See: https://github.com/gramps-project/gramps/blobtree/master/gramps/plugins/db/dbapi/settings.py

;BSDDB (Default):<code>database.backend:bsddb</code>

PostgreSQL;SQLite3:<code>database.backend:postgresqlsqlite</code>

SQLite3;PostgreSQL:<code>database.backend:postgresql</code> ;MongoDB:<code>database.backend:sqlitemongodb</code>

* [[PostgreSQL|Addon:PostgreSQL]] - experimental database support for Gramps 5.x ===MongoDB===MongoDB is an open-source document-oriented NOSQL database.  See also:* [[MongoDB]] - experimental database support for Gramps 5.x

DB-API is just one implementation of a generic DB interface. The class gramps.gen.db.generic.DbGeneric implements all of the methods of a database while the actual DB-interfacing code would be in a subclass of DbGeneric. For example, gramps.plugins.db.dbapi implements the DB-API SQL code. Other future versions need only implement a subclass. Other possibilities might be one of the so-called "no sql" database, such as CouchDB or [[DB-API_Database_Backend#MongoDB|MongoDB]].

All of the SQL statements are in a single file: gramps/plugins/database/dbapi.py. If we wish to write more abstractly than raw SQL using, say, SQLAlchemy, then we need to just re-implement that file. That will add a dependency, but will allow us to add Oracle and SQL Server to the list of supported SQL engines, and allow us to write more sophisticated and optimized SQL. Of course, as this is a plugin, any new backend can be added to addons at any time. Two other possible future backends are [[DB-API_Database_Backend#MongoDB |MongoDB]] and CouchDB. Both of these match our data better (hierarchical), but are also newer/less stable, and limited in variability. Sqlite file structure is well-known, backwards compatible, and rock solid. Postgresql provide server/shared abilities.