Jump to: navigation, search

Database Query API

75 bytes removed, 23:21, 25 January 2016
no edit summary
[This is a work in progress.]
= Schema API Overview =
Starting with Gramps 5.0, we will have two database backends, Berkeley DB (BSDDB), and [Python's DB-API](https BSDDB is a data store with much of the database code in Python. DB-API is a common interface to the popular SQL link title]
WeStarting with Gramps 5.0, there are two database backends, Berkeley DB (BSDDB), and [ Python'll need to keep s DB-API and ]. BSDDB both working for at least is a version or twodata store with much of the database code written in Python. Note that we'll We have dependencies on both used BSDDB and sqlite3 in Gramps for nowmany years. DB-API is a common interface to the popular SQL engines.
Previously, Gramps was a very modular design when it comes to accessing the data. For example, consider getting the People for the flat view. First we get a cursor that iterates over the data. Then we sort it, on whatever criteria we have requested. To sort the data, not only do we need to iterate over all of the data, but we need to unpickle and turn the raw data into Person objects. Of course, it would be much faster if we can store the order in an index, so that we can just get the data that we need. This is even more important when we only want to see a filtered segment of the database, say those people who have a surname of "Smith."
In order to make this fast, we need to know the filter information, and sort order when we ask for the data. With SQL we can simply add WHERE clauses and ORDER BY clauses to the basic SELECT statement. But these are only useful if we can have indexes on the relevant data.
This is made more default difficult because Gramps uses a hierarchical representation of data. For example, we might wish to have the People data sorted by "surname, given" of the primary_name. But that information is actually in:
* person.primary_name.surname_list[0].surname
respectively. We could make special fields for these, and special indexes. But it would be much more flexible if we could create a variety of ad hoc queries on the fly.
The BSDDB datastore doesn't have any schema, which means that it has no idea of "gramps_id" or "primary_name" or any field. I've An idea of schema has been working on adding a schema to primary objects for a developed over the last few years. This makes possible the Database Differences Report, without having to write any field-specific code: the data knows its own structure.
The schema idea has been augmented with additional methods based on the idea of "fields". Now, you can ask a person object:

Navigation menu