I am presently experimenting to “unhide” record structure in database. The current way of storing data in SQLite is to take genelogical data and to stuff it into a BLOB. The record contains only auxiliary service fields (gramps_id, handle and a few index fields) besides this BLOB. As such, data is opaque and the DB can’t be used outside Gramps.
I have started to unravel some primary objects using their JSON schema to automatically generate TABLE SQL statements (or equivalently ALTER TABLE statements). Incidentally, this requires some modifications to the present table architecture: more TABLEs are needed to represent the
I work by guessing the JSON “components” of the schemas.
=> Is there somewhere a formal specification of the JSON used in Gramps?
This would greatly simplify implementation of a “pure” SQL database.
Incidentally, several questions about design arise. Maybe they should be asked in a separate post? One of them is about parson main name. In the vast majority of cases, a person is known under a single name and it is justified to store this name inside the Person record. However, a person may be designated by several names. These names are stored in an “array” of Name secondary objects, described by their own JSON.
Including the main name in Person needs to go through decoding a nested schema (possibly recursively) and this seriously complicates matters (notably assigning a user-visible name to the added fields). Notwithstanding performance issues, wouldn’t it be more consistent to have the main name as a Name record and only store an id or index in the Person record?
There are other examples of the same issue among other primary objects.