I am relying on JSON object definition to automatically generate SQL TABLE description and partially to implement an interface between existing code and my “pure relational” SQL DB.
It works fine with so-called primary objects (those which are listed in the left pane of the main window). “Secondary” objects are, in a simplistic way, those which are accessed through lists in primary objects (they show up as tabs in primary object editor windows).
JSON in class Address (gramps/gen/lib/addres.py) exhaustively enumerates all fields for an address, from “street” to “phone”. But code in serialize() and unserialize() extract this information from a LocationBase object. This means I must “format” specially data extracted from the DB so that unserialize() will find what it expects.
The same can be said for Location.
LocationBase contains no JSON schema, which is OK for me.
In other objects, when a sub-object is needed, it is described indirectly with a <class_name>.get_schema(). My generator interprets such a statement as a reference to another object in the DB. Usually, this is an “array” (a list of related objects). However it of course is not the good track for an address or location. And the discrepancy between enumeration and reference to a sub-schema causes my processing to error out. It also means I must make a special case of address/location.
Considering a Location is a special case (a subset) of an Address, couldn’t we get rid of Location and in the same time merge LocationBase into Address?
Address is used in Person and Repository (why not in Family?). Location is used only in Place.
Researcher also inherits from LocationBase but has no JSON schema as it goes into metadata. It is a very special case and it doesn’t really matter how it is implemented; I read in one question (but don’t remember which otherwise I’d have posted a link) someone suggested to record the researcher as a Person with a special tag or type. In this case, no trouble because a Person can have an Address and much more.
The difference is Address may have citations and notes attached. I admit it is redundant in a Place where the notes already target the place itself, the address only being an additional information. But who knows? The Place could describe a building with 2 addresses because the street name changed. In this case a note on the address makes more sense for me than on the Place itself.