A tree in multi-tree gramps-web is an identifier of which family tree you want to work with. All trees are stored in the same tables, and so the treeid allows you to operate as if there is only one tree’s data. treeid + handle is then a new handle.
1 Like
I thought we might leave it there for a version, as a backup, in case there is an issue and we need to convert again.
There is a standard format in SQL that appears to work for SQLite, MySQL, and PostgreSQL using syntax based on the JSON_EXTRACT(). That looks like:
SELECT json_data->>'$.tag_list[0].name' FROM person;
That is “slow” by SQL standards (JSON data is parsed for each row). Much faster than doing it in Python! But there are other faster options. SQLite has Generated Columns that can be virtual or stored. Looks like PostgreSQL has similar functionality.
1 Like
I think the confusion here is that we have previously been discussing the idea of a tree_id to indicate trees that have been derived from a common source tree.
I’m prioritising Doug’s pull requests at the moment. When I have time I will get around to looking at all other contributions.
2 Likes
Does it make sense to have a “JSON Inspection” gramplet (expert or developer audience) that shows a JSON representation of the active object with its secondary objects?
It would allow users to quickly determine if an object is getting funky.
Maybe… these are pretty hard to read. Here is an example:
{"handle": "02NKQC5GOZFLSUSMW3", "change": 1185438865, "private": false, "tag_list": [], "gramps_id": "I1487", "citation_list": ["c140d245cc614c5c140"], "note_list": [], "media_list": [], "event_ref_list": [], "attribute_list": [], "address_list": [], "urls": [], "lds_ord_list": [], "primary_name": {"private": false, "surname_list": [{"surname": "\u041c\u0435\u0434\u0432\u0435\u0434\u0435\u0432", "prefix": "", "primary": true, "origintype": {"_class": "NameOriginType", "value": 1, "string": ""}, "connector": "", "_class": "Surname"}], "citation_list": [], "note_list": [], "date": {"format": null, "calendar": 0, "modifier": 0, "quality": 0, "dateval": [0, 0, 0, false], "text": "", "sortval": 0, "newyear": 0, "_class": "Date"}, "first_name": "Mary", "suffix": "", "title": "", "type": {"_class": "NameType", "value": 2, "string": ""}, "group_as": "", "sort_as": 0, "display_as": 0, "call": "", "nick": "", "famnick": "", "_class": "Name"}, "family_list": ["IRMKQCD49F9P9QTQRT"], "parent_family_list": [], "alternate_names": [], "person_ref_list": [], "death_ref_index": -1, "birth_ref_index": -1, "_class": "Person", "gender": 0}
1 Like
At the moment in the SharedPostgreSQLAddon, the tree ID is a property of the database connection, so it cannot be modified by any of the “normal” database access methods like get_person_from.... I consider that to be an important security feature to keep data from accidentally leaking between users in a multi-tenant environment, so I would strongly suggest to treat handles and tree IDs on a different footing.
1 Like
Perplexity indicates that there are 3 basic styles for JSON representation: compact, commented and pretty (for printing)
If a JSON Inspection Gramplet used the “Pretty”, wouldn’t it be a lot easier for a Human to inspect?
It is easy to output JSON in a pretty format.
SQLite has the json_pretty() function and the python json module has the indent option which does the same thing.
1 Like
I suspect that a JSON inspection would be very handy when diagnosing problems such as the current discussion: Parent Citation.
Sometimes Citations are buried deeply as secondary objects of secondary objects … or even deeper. So, identification of where missing Citations are attached helps identify where a report needs improvement.
Cross-reference related feature request:
0012436: “Deep References” gramplet (add optional configuration of existing…