no edit summary
[This is a work in progress.]
Schema API =
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 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:
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 been working on adding a schema to primary objects for a 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: