Best practices for saving addon specific data

Hi!

I’m thinking of making an addon to link my gramps database with online services. My current idea would be to save these online data as json for each linked person so that I can check later what has changed.

Where should I save these data?

It seems as though linking a JSON Media object would have the least chance of making the Tree excessively large & slow.

The individually-sized-portion scrapes in JSON could be hung as a dated media object, placing that media object in a subfolder of your Preferences Media path. If you anticipate a large & ongoing volume of compares, you could create dated-named subfolders for scraping sessions.

If you do a full Tree scrape to a JSON, you could create a Private dummy Person as an anchor.

Some other features that would be nice: a drag’n’drop location “inbox” for when an export file from an online service is the source rather than a scraped JSON. Where the media object will be moved & re-pathed when processed. (So only unprocessed objects remain in the inbox.)

Another nice option would be to leverage the import plugins so that the compare source file to be any format. (Like comparing 2 Gramps backup files to generate the delta file.) The Import Merge tool add-on already does something similar. Except it does its compare of an external file against the loaded tree. The compare of 2 dated media objects (or more than 2 for a change history?) external JSONs would be unique.


One of the places that the Import Merge Tool fails to be effective is that there is no option to save the compare results so that a LARGE merge task can be whittled upon in multiple sessions.

Note that if you decide to use an InBox or Media GTK File Chooser, you can set a button on that chooser to shortcut any saved filepaths:

  • Bookmarks: are created by the user, by dragging folders from the right pane to the left pane, or by using the “Add”. Bookmarks can be renamed and deleted by the user.

  • Shortcuts: can be provided by the application. For example, a Paint program may want to add a shortcut for a Clipart folder. Shortcuts cannot be modified by the user.

  • Volumes: are provided by the underlying filesystem abstraction. They are the “roots” of the filesystem.

See also:
https://lazka.github.io/pgi-docs/Gtk-3.0/interfaces/FileChooser.html#Gtk.FileChooser.add_shortcut_folder

What about just storing it as a Person attribute?

Isn’t the potential size of a JSON too large for a Attribute?

At least regarding the data schema, I don’t see any length limitation:

Not sure if there is any limitation in the UI, but it shouldn’t matter as I’m assuming the addon would anyway just store/process the JSON.

My concern was the practical limit of the Edit Attribute window. It displays only a single line of text with no scroll controls. So it would be impractical to manually examine even a minimal JSON within the GUI.

image

It seems like it would be better to select somewhere to hang the data that already supports displaying larger blocks of text.

A different approach than external files or the Attributes internal data structure.

There is an existing add-on that a Note in the Associations to store specially formatted data.

The DNA Segment Map Gramplet add-on uses a “DNA” custom type Note in the Association element.

You might adapt this add-on code as a springboard for your proof of concept.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.