Changes

Jump to: navigation, search

Database Formats

814 bytes added, 09:39, 19 March 2014
m
Detailed Changes
[[Category:Developers/General]]
[[Category:Developers/Reference]]
 
{{languages|Database Formats}}
 
 
 
==History==
GRAMPS Gramps default data format has been evolving evolved over time. Each major change in format usually results in an increase in the major version number.
===GRAMPS Gramps 1.0 and earlier===
GRAMPS Gramps 1.0 used XML as its default format. This format is portable and easily read by both computers and people. It has two major issues that caused problems when it was used as the default format.
* Slow to load and save. The entire file had to be parsed to load the data, and parsing XML is not fast. Similarly, to save any changes, the entire file had to be written. People with larger databases (thousands of persons) found the load and save times to be unusable.
* Consumes a lot of memory. The XML format required that all data be loaded and stored in memory. Larger databases could consume all memory on the system and as a result bring the system to a virtual halt.
===GRAMPS Gramps 2.0===
To solve the capacity issues, GRAMPS Gramps 2.0 switched to using the Berkeley database, using the ".grdb" extension to identify the file. All database information was stored in this file. This resolved both the load/save time issues and the memory consumption issues. Using a real database backend allowed us to only load the data into memory when we needed it.
The grdb format was a significant step forward for GRAMPSGramps. However, it was susceptible to data corruption. Since data commits were not atomic (all related changes saved at once), data could get corrupted if an error occurred while a change was being made.
===GRAMPS Gramps 2.2===
GRAMPS Gramps 2.2 started using the transaction capability of the Berkeley database. This feature ensures that all related data is committed at once. So, if an error occurs while that data is being saved, the database remains intact. Either the entire set of changes makes it to the database, or none of the changes make it.
The problem with the approach in 2.2 is that a single file (the grdb file) is no longer enough for the Berkeley database to handle the data. An "environment" directory is needed to store the transactions log files. A place was needed to keep these files so that the user would not delete them. An environment directory under the ~/.gramps directory was chosen for this. The log files are mapped to the database using the path name of the original grdb file.
This works very well as long as the file is never moved. If the user renames the file, restores a backup of the file, or copies it to another machine, [[Recover corrupted grdbRecover_corrupted_family_tree#Why this corruptionWhat_causes_this_corruption.3F3F_2|the file will no longer work]], since it would no longer correlate to the log files stored under ~/.gramps.
==The Future - GRAMPS Gramps 3.0==
A new approach was taken with GRAMPS Gramps 3.0. While the Berkeley database is still used, the user will no longer see a file. Instead of the actual database file, user opens a symbolic database name. This name will map to a subdirectory under ~/.gramps directory which contains all the needed database files.
Since all the files will be in the same directory, advanced users can make a backup of the entire directory, preserving the entire data. New users, who may not be familiar with the Linux filesystem, will not have to worry about finding their database, since a new Family Tree Manager will replace the old Open File dialog.
The new Family Tree Manager replaces the File Open dialog. Version 3.0 does not work on files, but on Family Tree Databases. Since there is no file to open, a file open dialog makes no sense. The Open button has been replaced with a Family Trees button. Clicking this button brings up the Family Tree Manager, shown below.
[[Image:Dbmanager01ManageFamilyTrees-40.png]]
The Family Tree Manager allows the user to create a new database, rename an existing database, delete a database, or load a database. All databases appear in the list, so the user does not need to worry about where the databases are located. If a database is open, an icon will appear next to the name.
==== Versions ====
If the RCS revision control system is installed on your system, GRAMPS Gramps allows you to archive specified versions of your database. To save a version, open the Family Tree Manager and select the opened database. Simply clicking on the Archive button will save the current version to the revision control system. If a database has one or more saved versions, the databases appear as a tree view, with the available versions displayed under them.
[[Image:Dbmanager03.png]]
The advantage of storing versions is that you can go back to one of these saved versions. To select a version to restore, select the version and click on the Restore button.
[[Image:Dbmanager04FileManageFamilyTrees-ArchiveSelectToExtract-40.png|Selecting a version to restore]]
GRAMPS Gramps will extract the version into a new database. The database name is based on the original database name and the revision name.
[[Image:Dbmanager05FileManageFamilyTrees-ArchiveExtractedVersionShown-40.png|Restored version]]
Versions may be deleted and renamed.
==== Multiple users ====
Unlike previous versions, GRAMPS Gramps 3.0 supports limited sharing of databases. Multiple users may edit the same database, just not at the same time. The Family Tree Manager will identify a database that is open for another user, and you will not be able to load the database until the other user has closed the database.
[[Image:Dbmanager06.png]]
===Automatic Backup Files===
To protect against file corruption problems in the Berkeley database, GRAMPS Gramps 3.0 will generate a backup file at exit if any data has changed.
Unlike in 2.2, the backup files are not in XML format. The new backup files are a dump of the database tables. This allows the data to be saved quickly. One backup file exists for each primary table in the database. The backup files are not visible to the user, being held in the database directory.
== Why no simultaneous access? ==
From time to time people want to use GRAMPS Gramps for collaborative research, and are then stopped as GRAMPS Gramps does not allow simultaneous access. That is, you can simultaneously access the database, but this typically results in corrupt data, destroying your database.
The motivation for this is the following:
#Who to maintain this code? The core developers don't need this feature. Somebody should join the team to make this happen.
Technically, BSDDB can be made to work with a server environment. However, in GRAMPS Gramps we give the <code>env.open()</code> the <code>DB_PRIVATE flag</code>. The docs say:;<code>DB_PRIVATE</code>:Specify that the environment will only be accessed by a single process (although that process may be multithreaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads.
:This flag should not be specified if more than a single process is accessing the environment because it is likely to cause database corruption and unpredictable behavior. For example, if both a server application and the Berkeley DB utility db_stat are expected to access the environment, the DB_PRIVATE flag should not be specified.
:Source: [http://pybsddb.sourceforge.net/api_c/env_open.html env_openDB_ENV->openNote however that consecutive access from different places to the same underlying database is possible with Gramps 3.0, so a collaboration based on time sharing (using different hours to input data in Gramps) is possible. == Detailed Changes == This table lists the database changes for each version. {|{{prettytable}} !Gramps!Database!Changes from previous version|- |Gramps 4.1 (trunk)|17|# added Tags to Event, Place, Repository, Source, and Citation# Source and Citation objects gained a private flag (???)# Source.data became SourceAttributes# Added checksum field to Media# Added PlaceRef and Place Hierarchies|- |Gramps 3.4 - 4.0|16|# converted SourceRef to new Citation object|- |Gramps 3.1 - 3.3|15|# added Tags to Person, Family, and Note# added Surname list# removed Marker |- |Gramps 3.0|14|# added newyear to Dates# Replace plain text with StyledText in Notes|- |Gramps 2.x|13|# changed name formats# |}
Note however that consecutive access from different places to the same underlying database is possible with GRAMPS 3.0, so a collaboration based on time sharing (using different hours to input data in GRAMPS) is possible.[[Category:Developers/General]][[Category:Developers/Reference]]

Navigation menu