Skip to content

Handle graph updates after commit as a transaction

Carlos Garnacho requested to merge wip/carlosg/transact-graphs into master 
After a graph is created/deleted, we update immediately our graph
accounting. This however didn't take into account that graph operations
may happen within a transaction, so a readonly interface being spawned
at the right time might consider those graphs as existing its query even
though they are not attached yet.

This situation would resolve itself after the last graph is processed,
and the transaction committed, but for that query it would fail like:

  In service 'dbus:org.freedesktop.Tracker3.Miner.Files': no such table: http://tracker.api.gnome.org/ontology/v3/tracker#Audio.nfo:Audio

In order to fix that, handle changes to the known graphs as part of the
transaction, only making it effective after the change is committed, and
database interfaces would correctly find the graph databases when updated.
This makes readonly interfaces aware of the graph changes after the
transaction is committed, not before.

Of course, this means the operation should be rolled back if the
transaction failed. Also do that.

Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/231

Merge request reports