1. SPARQL Internals
Deprecation warning
For up-to-date documentation of SPARQL as understood by Tracker, see https://gnome.pages.gitlab.gnome.org/tracker/docs/api-preview/libtracker-sparql-3/sparql-and-tracker.html and https://gnome.pages.gitlab.gnome.org/tracker/docs/api-preview/libtracker-sparql-3/sparql-functions.html
1.1. Properties
1.1.1. tracker:modified
The tracker:modified feature is not well understood by all. This is seen in occasional bugs reports the team manages.
There was a blog by Tracker maintainer Philip Van Hoof describing synchronizing your application's data with Tracker's RDF store which gives a good account of how you can use tracker:modified.
1.1.1.1. Example 1
Say you wanted to create a stored hashmap<subject, title> to your file system as title-cache.txt. You'd do this:
select ?s ?title ?modseq { ?s nie:title ?title ; tracker:modified ?modseq }
You write title-cache.txt with ?s and ?title and you write a file title-cache-modseq.txt that contains the maximum value of all ?modseq you saw.
Time passes and titles gets changed in Tracker's RDF store. Your application wants a new title-cache.txt. But it doesn't want to fetch all titles and subjects, it just wants to know the ones that got changed.
So it reads title-cache-modseq.txt and takes that maximum value of the last time, let's call it $last_modseq. Now it does this:
select ?s ?title ?modseq { ?s nie:title ?title ; tracker:modified ?modseq . FILTER ( ?modseq > $last_modseq ) }
It updates title-cache.txt with the ?s and ?title it received (it received a delta, not the complete list, due to the FILTER). Again, we write the maximum value of all ?modseq it received in title-cache-modseq.txt
This can go on to keep title-cache.txt up to date. It's an unsigned 64 bit number and we reset it to 0 after overflow.
The brilliant minds now understand that if ever their $last_modseq is larger than the ?modseq of the resource you most recently changed, we had the 64 bit unsigned number overflow in tracker-store. We didn't design to make detecting that overflow easy or something, because while hoping to reach the history books too we thought that unsigned 64 bit ought to be enough for everybody.
If you guys after having done unsigned 64 bit amount of transactions on tracker, must have your title-cache.txt updated with least amount of delta, I'm sure you can also get the time to develop detecting the overflow.
The tracker:modified property should not be used for any other purpose than synchronization like explained above.