Skip to content

libtracker-sparql: Fix actual 0-path matches in ? and * path operators

Carlos Garnacho requested to merge wip/carlosg/zero-or-more-fix into master

From the main commit:

These operators ("zero or one" and "zero or more" respectively) so far have
worked on the prerequisite that the contained property path has at least
one match with the given constraints. E.g.:

  SELECT ?u { <URI> nie:interpretedAs? ?u }

Would return no results if the given uri had no nie:interpretedAs, but here
we still want to have the 0-length match, regardless of there being a match
or not.

This commit fixes this by making these common table expressions look for
"self" in the rdfs:Resource table, this is ensured to always match as long
as the resource exists.

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

Although the MR also fixes the performance regression that happened in "tracker3 info" and possibly other places where queries with unrestricted predicates happen.

Merge request reports