Writeback is never triggered

The functional tests for writeback are failing, and it seems to be because writeback notifications do not work.

The expected process for writeback seems to be this:

1. tracker-store receives an INSERT or DELETE update

2. the tracker-store Tracker.Writeback.check() method is called

3. if the INSERT or DELETE was in the default graph, tracker-store queues the Writeback signal (on org.freeedesktop.Tracker1.Resources.Writeback interface)

   • The parameters of this signal are: the subject ID that was updated, and the list of RDF types that were affected

4. tracker-miner-fs receives the Writeback signal in the tracker-writeback-listener.c module, process_event() function

5. This function executes the following SPARQL query:

    SELECT ?resource tracker:uri(~) {
        ?resource a rdfs:Class .
        FILTER (tracker:id (?resource) IN (~))
    }

   where the first ~ is the subject ID that was updated, and the second ~ is a list of the IDs of the RDF types that were affected

6. When this query returns, rdf_types_to_uris_cb() executes. It collects the URN of the subject that was updated, and the URI of each RDF type that was affected. Then, it runs another query:

    SELECT ?url '~' ?predicate ?object {
        <~> a nfo:FileDataObject .
        <~> ?predicate ?object ; nie:url ?url .
        ?predicate tracker:writeback true .
        FILTER (NOT EXISTS { GRAPH <urn:uuid:472ed0cc-40ff-4e37-9c0c-062d78656540>
            { <~> ?predicate ?object }
        })
    }

   That long graph ID is for the Tracker miner-fs graph (see TRACKER_OWN_GRAPH_URN). The ~ is the URN of the subject that was updated.

7. When this query returns, sparql_query_cb() gets the file URL from the result and makes a GFile instance. It checks that the file still exists, and if so calls tracker_miner_files_writeback_file().

8. That function, in tracker-miner-files.c, updates the miner->private->writeback_tasks array with the GFile instance, and emits the writeback g-signal.

9. The g-signal triggers the miners/fs/tracker-writeback-dispatcher.c:writeback_dispatcher_writeback_file() function, which calls the PerformWriteback method on the org.freedesktop.Tracker1.Writeback D-Bus object

10. The tracker-writeback daemon actually wakes up and writes to the file.

So, that's the theory. In practice, the process always stops after step (6) because the query never returns any results.

This is because tracker-store doesn't really support named graphs, it only pretends to, and so the update from step (1) actually already appears in TRACKER_OWN_GRAPH_URN. In fact, replacing that graph URN with anything else will also return a result. But the writeback code appears to assume that an INSERT into the default graph will not update Tracker's own graph.