==Introduction== This document describes the basics of the underlying GRAMPS database. This is not intended to be a reference manual, but an introductory programmer's guide to using the GRAMPS database access routines . If you are a looking for documentation on how to use the GRAMPS system as a user instead of as a program developer , it can be found on the [http://gramps- project. org/ index. php?module = pagemaster&PAGE_user_op= view_page&PAGE_id= 7 GRAMPS documentation web page ]. Separate [ http:// developers. gramps-project.org/ devdoc/ api/ API Reference Documentation] is available .
GRAMPS is written in the [http://www.python.org Python] language. A basic familiarity with Python is required before the database objects can be effectively used. If you are new to Python, you may wish to check out the [http://docs.python.org/tut/tut.html Python tutorial].
Primary objects are the fundamental objects in the
GRAMPS database. These objects are:* [http:// developers.gramps-project.org/ devdoc/ api/ public/RelLib. Person- class. html Person] - Contains the information specific to an individual person.* [http:// developers.gramps-project.org/ devdoc/ api/ public/RelLib. Family- class. html Family] - Contains the information specific to relationships between people. This typically contains one or two parents and zero or more children.* [http:// developers.gramps-project.org/ devdoc/ api/ public/ RelLib. Source- class.html Source] - Contains the information related to a source of information.* [http:// developers.gramps-project.org/ devdoc/ api/ public/RelLib. Place- class. html Place] - Contains the information related to a specific place.* [http:// developers.gramps-project.org/ devdoc/ api/ public/RelLib. MediaObject- class. html Media Object] - Contains the information related to a media object. This includes images, documents, or any other type of related files.* [http:// developers.gramps-project.org/ devdoc/api/ public/ RelLib. Event- class. html Event] - Contains the information related to an event. The event is treated as a primary object in the database, it currently does not appear as a primary object to the end user.
Primary objects are treated as tables within the database. Individual components that compose the primary object are stored as individual items in the database.
Each primary object has a unique handle associated with it. The handle serves as both a unique identifier and as the key into the database. This handle is generated using the current timestamp along with two 32-bit random numbers. The resulting value is converted to a text string to provide a hashable handle.
For this reason, it is always necessary to have reference to the database that contains the objects with which you are working.
The handle should not be visible to the end user, and should not be included in reports or displayed on screen. Instead, the
GRAMPS ID value should be used for this purpose. The GRAMPS ID is a user defined value for each object, but is not used internally to the database. This allows the user to change the GRAMPS ID without affecting the database.
Once created, the handle should never be modified.
In this case, even though person1 and person2 represent the same person,
but are distinct objects. Changing the nickname of person1 does not affect person2. The person2 object will retain the original nickname.
Changes to the object do not become permanent until the object has been committed to the database. If multiple instances exist in memory at the same time, care must be taken to make sure that data is not lost.
Secondary Objects== Secondary objects are objects that are contained within primary objects. These objects include dates, addresses, and source references among other objects.
Secondary objects are treated as a single unit within the database. Typically, this means that the objects are stored in [http://www.python.org/doc/current/lib/module-pickle.html pickled] format.
GRAMPS provides a standard interface for all database objects. The GRAMPS database object provides the interface to the lower level database. Currently, three database objects are supported:
* GrampsBSDDB - the default database, providing access to a Berkeley DB database.
* GrampsXMLDB - provides in-memory editing of the GRAMPS XML database format.
* GrampsGEDDB - provides in-memory editing of a GEDCOM file.
All the database classes are inherited from a common base, so they provide identical interfaces.
===Transactions and Commits===
In order to support an UNDO feature, the database has the concept of [
http:// developers.gramps-project.org/ devdoc/api/ public/ GrampsDbBase. Transaction- class. html Transactions].
Transactions are a group of related database commit operations that need treated as a single unit. If all related commits are not undone as a single unit, the database can be left in a corrupted state. The UNDO operation will undo all the commits in the transaction.
# begin transaction
transaction = database.transaction_begin()
# Create new family, add it to the database. The add_family
# finish the transaction
database.transaction_commit(transaction, "Add family")
===Iterating through the database===
Frequently, it is useful to iterate through all the elements of a database.
GRAMPS provides two ways of accomplishing this. The first method involves getting a list of all the handles and looping over the list. This method is the easiest to implement. An example is below:
for handle in database.get_person_handles():
person = database.get_person_from_handle(handle)
A more efficient method exists, but is more complicated to use. The database can provide a [
http:// developers.gramps-project.org/ devdoc/api/ public/ GrampsDbBase. GrampsCursor- class. html cursor] that will iterate through the database without having to load all handles into memory. The cursor returns a handle, data pair. The data represents the serialized data directly from the database. It is the users responsibility to unserialize the data. An example is below:
cursor = database.get_person_cursor()
pair = cursor.first()
===Getting notification of changes to the database===
If you have widgets that are displaying the content of the database tables you need to be aware that the database can change. Records may be added, removed or updated by other parts of
GRAMPS and your widget must show these changes. The GRAMPS database provides a signalling mechanism that can be used to notify your widget of changes to the database. The documentation for the ((GrampsDBCallback)) class provides a description of the signalling mechanism. For most code that uses the GRAMPS database all that is required is for callback functions to be connected to the correct signals. For example:
A full list of the signals that are emitted from the database can be found at the top of the <tt>GrampsDbBase</tt> class in the <tt>