Difference between revisions of "GEPS 032: Database Backend API"

From Gramps
Jump to: navigation, search
(Process)
(Process)
Line 3: Line 3:
 
This is an idea refined from [[GEPS 010: Relational Backend]]. However, without the relational components.
 
This is an idea refined from [[GEPS 010: Relational Backend]]. However, without the relational components.
  
==Process==
+
==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.
 
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.
  
 +
==Backends==
 
Backends to consider:
 
Backends to consider:
  

Revision as of 23:50, 29 December 2014

This proposal defines a complete Database Backend API so that we can have drop-in replacement for BSDDB. This would allow the use of other databases, even relational/SQL backends, but used in a non-relational manner.

This is an idea refined from GEPS 010: Relational Backend. However, without the relational components.

Progress

The first step is to separate all of the gramps.gen.db code into reusable and extendable components. This has begun with the DictionaryDB 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.

Backends

Backends to consider:

  • MongoDB
  • CouchDB
  • Sqlite - probably the best for our uses
  • CSV - spreadsheet
  • SQLHeavy - probably not... sqlite is a thin, robust, backwards-compatible-guaranteed layer. SQLHeavy has too much that we do not need.
  • Libgda

Issues

  1. Need to be able to represent transactions
  2. Need to be able to undo/redo

See Also