1,610
edits
Changes
From Gramps
no edit summary
https://github.com/gramps-project/gramps/tree/geps/gep-032-database-backend
Identify the items that:
* need to be fixed
* are too BSDDB specific (some tools?)
* could be abstracted away from details
===Step 2===
Once a full Gramps Database class is created, there needs to be a way of:
# selecting which backend to use for new databases[DONE]# selecting the database to load (Family Tree Manager)[Prototype Working; needs to come from plugins]
We will use the directory structure, as we do now. In each directory, the type of database needs to be identified. This could be done in two ways:
We should factor-out all BSDDB dependencies, and make BSDDB the first database backend plugin. The plugin API should include functions for:
* making a new database, given a directory[DONE]* loading the database, given the directory[DONE]
Other things that might need to be changed:
</pre>
However, this has to be done in the right place, and can't (as far as I can see) be embedded in an the imported database plugin.[DONE]
==Progress==
The first step is to separate all of the gramps.gen.db code into reusable and extendable components.
This has begun with the [http://sourceforge.net/p/gramps/source/ci/master/tree/gramps/gen/db/dictionary.py DictionaryDB] {{bug|4972}}, which is a in-memory replacement for the BSDDB. Still needs the indexes, and metadata support (gender names, bookmarks, etc). Also, the Dictionary transaction is non-existent.
Currently, the best working replacement backend is gramps.webapp.dbdjango"dictionarydb".
We can develop backends that work directly on Exported formats. For example, our SQLite export would make a fine backend. Others to consider: GEDCOM and CSV. These would probably use a DbDictionary, and simply import/export on load/close (would lose data if power outage; would be fast as in-memory, slow on start/stop).
==Other Backends==