While trying to compile links for a Glossary entry about Object Reference Editors (to contrast with the Object Editors entry), I had problems working backwards from a Citation when trying to discover where it was linked to an object.
The References tab said that the Citation was attached to a Person.
But exploring the Source Citations tab for the Person did not list that Source (or Citation). And the Biography quickview report failed to list that Source.
After much MUCH frustration and exploration, I finally found it attached as a Source for 1 of the Alternative Names.
From my present exploration of the code, this difficulty comes from the data model structure interwoven with Python representation. I think it is time for restructuring the data model but this has to be discussed because of the implications on compatibility.
My opinion is that “genealogical objects” as currently implemented try to contain too many non-individualised sub-objects. It is the case notably for all array data: these arrays are contained in the “primary” object instead of being a set of separate elementary “sub-objects”. This aggregation prevents a clean SQL implementation. In a relational database a 1-to-n relation (a simple array) is represented by an independent TABLE where records have a column pointing back to the owning primary record. The case of m-to-n is slightly more complicated but not that much: there is an intermediate TABLE for the arrays (plural is intentional as m may be larger than 1) elements with records pointing back to the owning primary and pointing forward to the owned sub-object.
The primary objects have “standard” “annotation” entries attached to them: notes, attributes, citations, media, tags. Some array sub-objects are abstract enough to be accompanied by “annotation” entries themselves. Unfortunately, since these sub-objects do not correspond to any visible primary concept in Gramps, a back reference can’t be meaningfully attached to them. Thus the back-reference crawls upwards to the primary object.
This is the case for addresses, attributes, LdsOrd and names.
I even found a weird case with sources and citations (I don’t remember exactly which one) where the back-reference will not point to source but to citation (or vice versa, need to re-experiment to disambiguate).
As it is, I don’t know of any easy way to answer your question. Since I’m working on a “pure” SQL implementation, I’m facing the reverse: finding the person owning the annotated name since the DB query returns the Name reference. I must then issue a secondary query to retrieve the Person.
That’s also true for citations associated to Reference to a media. May be it’s there you see your confuse citation and source issue since you can have a citation in Reference to a media associated to a source which can be a citation from that source
My goal is to make genealogical data available to other applications through access to the DB. I had a look to the ZODB Wikipedia article and I am a bit frightened. Python objects are stored into the database as opaque records (There is no declaration of the data structure […] so new fields can be freely added …). This means no external application/program can use the DB without importing part of Gramps code.
ZODB looks to me as persistent storage of Python data between sessions, not as a “traditional” DB. By “traditional”, I mean I expect some independent operations can be done on the DB outside the program which created it, such as queries, statistics, maintenance, …
In a traditional RDBMS, there is a schema describing the data structure. Hence, an external program can use the data without having to know details about Gramps internals. This comes to a price: adding new fields requires to change the schema (and external programs). This is expensive but the structure is always clearly exposed.
Having a separation between Python and storage organisation could have many advantages. For instance, Narrative Web could be implemented as a set of queries against the DB without the need to generate individual static HTML pages. In this dynamic approach, displayed pages are always up-to-date with regard to the DB. We then trade disc space for time to dynamically generate the page.
Report generators could also be made independent from Gramps, perhaps participating in more stability.
Yes. Add also EventRef, ChildRef, PersonRef, PlaceRef and RepoRef at least for Notes (and Attributes?).
The Gramps data structure consists of a hierarchy of secondary objects contained within primary objects. What you need is a list of secondary objects which contain the reference. It would be fairly easy to write some code to do this.
It would often be useful to have Clipboard-like Gramplet for each category that simply included the hierarchical cascade of Secondary objects to a primary.
Is there a function that gathers them all? The speed of the Relationships view being populated with secondary info and comprehensiveness when exporting of a Single Person both seem magical.
Although I belatedly realize the flattened hierarchy wouldn’t help in this case. There isn’t a clipboard-compatible object for an Alternative name where the Citation had been added. So I’d still have no clue that’s where I had needed to look.
solutions could possibly address - 0012436: “Deep References” gramplet (add optional configuration of existing “References” gramplet)
