How to tell genealogical data has changed?

Development
1

You change data through various “editors” which can invoke “sub-editors”. For example, you patch a person data in the person editor (file gui/editors/editperson.py) but modifying the name or adding a new one is done in the name editor (file gui/editors/editname.py).

When you hit OK, a global test is made to see if data has really changed before committing to the DB. If nothing has changed, you don’t write back into the DB. This global test is method data_has_changed() of class EditPrimary. It compares serialised current object with serialised original object (which may be an “empty” object in case of creation).

This test is fine with BSDDB backend (or its emulation with SQL). But it is too coarse for a smarter SQL schema where a Gramps genealogical object is spread over several TABLEs. For example, names are stored in a different TABLE than persons because a person may be known under several names.

In such an approach, not all “components” of a primary objects have changed (I am thinking mainly of the various lists like events, attributes, tags, notes, …). It is then a pity to write back unchanged records to the DB.

This can be solved by keeping a “dirty” flag for the components (and the primary object). The problem is to manage this flag.

Is there a Gramps signal (not a standard GTK+ signal) which reports changes to a genealogical object in an editor? How is handled a change of ordering within lists (e.g. what happens when events are reordered according to some criteria like date or participant?)?

2

Gramps emits database signals for add, update and delete events for all primary objects. The list views listen for these signals and update the underlying models as necessary. For example when an event date is changed an ‘event-update’ signal is emitted with the handle of the event that has been modified.

3

Thanks Nick but this is not what I’m looking for.

I am before DB sync where I decide or not to write back. The add, update or delete events will occur later. The idea is to avoid DB writes when there is no need to.

Very coarsely, if any value in an editor widget is changed, the dirty flag for the object corresponding to the editor (i.e. the primary object or one of its “components”) is set to true. When user presses OK, the dirty flags are interrogated to enable the UPDATE requests.

I’d rather not create a new signal and connect it to the widgets as this would mess up dialog setup. Also, connections would necessarily be specific to each editor, making code more complex and less maintainable.

4

I assume you are writing a relational database backend.

If so, have a look at GEPS 010: Relational Backend. Doug Blank investigated this in some detail.

The old mailing list thread Lazy Evaluation in Gramps may also be of interest. Although this is about reading from rather than writing to a database.

It is also possible to generate a JSON patch showing the data changed by an editor. I wrote a small proof of concept in anticipation of our raw data format changing to JSON in the future.