| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the endpoint waits to write the full cursor contents before
replying to a Query D-Bus request. This relies on the caller side
simultaneously issuing the D-Bus request and reading all data from
the cursor, so that on the endpoint side writing the cursor does not
end up blocking when the buffer grew too large.
This relies on the bus TrackerSparqlConnection side doing exactly
that, and splicing all cursor contents in a memory buffer, This is
however not friendly to an approach using input streams, since the
TrackerSparqlConnection side would read pipe contents incrementally
while iterating the cursor, but it didn't get it yet since the
endpoint will end up clogging the pipe and the Query request will
not be replied.
In order to fix this, reply the D-Bus request before writing the
cursor contents, so that the other end can get ahead with creating
a TrackerSparqlCursor that will stream the contents during iteration.
As a result the errors happening during writes are not forwarded to
the other end anymore, but since they would mostly consist of write
errors, it sounds likely the other end had some involvement in that
(e.g. dying or prematurely closing the cursor).
(cherry-picked from commit 425411307ea0487279fb768dd69368da4ac59bd4)
|
| | |
|
| |\
| |
| |
| |
| | |
Backports for 3.3
See merge request GNOME/tracker!521
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We are just looking at the default graph when initializing nrl:modified
after opening an existing database. Since the default graph possibly
only contains part of the data, we are possibly/likely missing the latest
sequence number if used on other graphs.
Check all graphs here relying on our virtual tracker_triples table, so
we are ensured to get the actual latest/greatest nrl:modified sequence
that was previously used from the union of all graphs. This ensures us
to get always a fresh sequence number for newly inserted data.
|
| | |
| |
| |
| |
| | |
And GType boilerplate generation. This enum is entirely unused
in the tracker code and is thus unneeded.
|
| | |
| |
| |
| |
| | |
Fix occasional build failures such as this one:
https://gitlab.gnome.org/GNOME/tracker/-/jobs/2101449
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The order of the returned resultset was implicit and up to SQLite, but
the order for this test started changing starting with SQLite 3.39.0.
Make the order explicit, so that SQLite implementation details don't
leak up here.
Closes: https://gitlab.gnome.org/GNOME/tracker/-/issues/370
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is not quite correct, but it is the most straightforward way to sort
of handle situations in our own Nepomuk ontology that superproperties have
different rdfs:range than their subproperties.
For these cases, handle the conversion of the value. Since the worst case
(and the one we happen to exercise) is about converting resource ROWIDs to
strings, handle this specific situation.
This helps in serialization and deserialization of this data, since the
ROWIDs were not something that could be replicated in other databases
without mismatches (e.g. the resource having a different ROWID in the
new database importing the data) or worse (e.g. cardinality or other
constraints broken).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
If a database/ontology has no fulltext-indexed properties, we do not
create a corresponding FTS table. Likewise, parser/locale updates
should not attempt to update it, or we will get a "SQL logic error"
poking non-existing tables.
Closes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/2278
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a connection is proxied through a TrackerEndpointDBus, there are
possibly 2 levels of TrackerNotifiers, one being used in the service
itself to trigger the DBus signal, and another on any listening client
handling those notifications.
However, both of these are doing an additional query to fetch the URN
for each of the notified elements. Since we only pass ROWIDs in the
DBus signal to make the signal data as compact as possible, we can
avoid this query on the service side. Any client listening to
notifications will perform its own URN queries anyway.
So avoid this piece of pointless busywork in the service side, and
special case that the internal notifiers used by endpoints should not
perform the query for URN data.
This does not make anything noticeably faster (perhaps endpoint signal
emission is a bit more snappy now, if anything) as all querying and
cursor handling happens lazily in a separate thread fairly detached
from the rest of the machinery. However it's still less CPU cycles
used overall.
|
| | |
|
| |\
| |
| |
| |
| | |
Backports for 3.3.x
See merge request GNOME/tracker!514
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since commit 6cf3168302350f3fd3ef7f8bf79022950563300e tracker sometimes
returns an unqualified row id to applications that are asking for
a fully qualfied blank node urn.
This is because sometimes it generates URN with a text type instead of
an integer type, and so `SparqlPrintIRI` fails to recognize it as a
blank node identifier.
The result is that gnome-photos fails to match up album collections internally
between different queries, because sometimes tracker returns the fully
qualified urn and sometimes it returns the bare row id.
This commit address the problem by introducing a cast in the query that is
returning the row id as text instead of as an integer.
Fix suggested by Carlos Garnacho.
Closes https://gitlab.gnome.org/GNOME/tracker/-/issues/363
(cherry-picked from commit 2a7509055e36d1d871e7da337d95f729e7d8c58d)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
There's no actual parser changes, but we want to trigger a
rebuild of all tokenization info in the FTS table. This will
have the side effect of fixing databases that got the FTS
table broken.
(cherry-picked from commit 26f5af29a9e7955025134454c28d342747d47265)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Every other path that fetches the array of previous values for
deletion also deletes the GValue from the cached array. This
place handling our almost unused, non-standard INSERT OR REPLACE
syntax, was missing this.
Since the handling of FTS updates later poke the cached values
to update all FTS columns, this may result in the deleted value
being inserted again in the FTS tree, resulting in another
unbalanced tree situation (as the actual column containing the
data and the token tree for the corresponding content-less column
in the FTS table differ).
An example of this situation is:
INSERT OR REPLACE {
<a> a nie:InformationElement;
nie:title 'title';
}
INSERT OR REPLACE {
<a> a nie:InformationElement;
nie:title 'title2';
}
SELECT ?u { ?u fts:match 'title' }
Returning matches for the old value.
(cherry-picked from commit 6067f032d3b7ed4614bedf840b4edc86165567e3)
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the SQL interface offered to update external content
and content-less FTS tables, updates on FTS columns must
happen as 2 separate updates, one to delete tokenization
data from the tree, and another to update.
Due to our own current implementation details, the FTS
table is synchronized per-row, meaning that we always want
a FTS update after a FTS delete, in order to synchronize
other properties properly. Fix the code to force one in
place, instead of relying on loosely related paths to set it.
This was unnoticed because most often FTS deletes are either
a part of an FTS update, or part of a resource deletion (thus
no FTS properties are left for the resource).
But with the right circumstances, a FTS deletion may come
alone, thus it would not trigger the later expected FTS
update. This may unbalance the FTS tree, causing
SQLITE_CORRUPT on later updates. An example of this is:
INSERT DATA {
<a> a nfo:InformationElement ;
nie:title 'b' ;
nie:identifier 'c' .
}
DELETE WHERE { <a> nie:title ?t }
Fix this situation by always scheduling a FTS update after
a delete. The FTS update will be opted out on actual full
deletes otherwise (concretely by early out due to the FTS
update having no actual changes).
Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/361
(cherry-picked from commit cb82665dc9eee21f3aea38f4d55c1f48440f562e)
|
| |\
| |
| |
| |
| |
| |
| | |
Documentation improvements
Closes #349
See merge request GNOME/tracker!497
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Paraphrase and complete some of the security considerations brought
up at the various SPARQL reference documents.
Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/349
|
| | |
| |
| |
| |
| |
| | |
Stress further the importance around ::block-remote-address and
GTlsCertificate, and mention that HTTP endpoints do not implement
updates.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This is missing in introspection annotations.
|
| |/
|
|
|
| |
This is something hotdoc can do for us, there is no need for an
script here.
|
| |\
| |
| |
| |
| |
| |
| | |
libtracker-sparql: Fix libtracker-remote-soup{2,3} modules linking
Closes #358
See merge request GNOME/tracker!501
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want to avoid meson version bumps, but this hack to ensure that GIR
generation depends on the soup modules (since they will be pulled at
runtime by g-ir-scanner during introspection) does not work across all
meson versions.
Use different hacks dependent on the meson version, so that the modules
are a build-time dependency of the GIR target.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The modules should link dynamically and not statically with
libteacker-sparql. Linking statically results in the modules and the
shared library to export definitions for the same GObjects, resulting
in type registration errors.
The tracker-remote modules however need access to the private
TrackerSerializer classes. Unless these GObject are made public, their
definition must be linked in the modules too. As the code implementing
TrackerSerializer and the specialized version is pretty small, the
simplest solution is to compile the sources twice, without going
through an intermediate library. The definitions being private to
libtracker-sparql and to the libtracker-remote-soup{2,3} modules,
having two defintions for them does not cause issues.
Fixes #358 and likely #350 too.
|
| |\
| |
| |
| |
| | |
Sparql compliance fixes
See merge request GNOME/tracker!503
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix some brokenness in dealing with the parse tree, and make the
algebra actually equivalent to the spec. There were two rough points:
- Negated inverse paths cannot be implemented on top of the inverse
path implementation. "<a> !^:prop <b>" must match all properties
from <b> to <a> that are not :prop.
- The combination of inverse and regular paths in a negated path
(e.g. "<a> !(:prop|^:prop) <b>") must intersect the inverse and
regular paths separately and join those with an alternate '|' path.
This makes negated property paths consistent with the definition
at https://www.w3.org/TR/sparql11-query/#sparqlTranslatePathExpressions
and following algebra.
|
| | |
| |
| |
| |
| | |
This column contains the object value as stored in the actual tables,
not a string representation.
|
| | |
| |
| |
| |
| | |
Ensure these are parsed correctly, and are able to contain quotes
of the same nature.
|
| |/
|
|
|
|
|
|
|
|
|
| |
As our parser rules are ordered by greediness, and as """str""" and
'''str''' long string forms partially match the shorter string literal
forms, we mistakenly parse these as an empty string (e.g. "" or '')
followed by "garbage".
We should set long string literal forms first here, so these are tried
before the short string forms. Fixes handling of long strings all through
the query language.
|
| |\
| |
| |
| |
| | |
ci: Rebuild tree before running tests
See merge request GNOME/tracker!500
|
| |/
|
|
|
|
|
|
|
|
|
| |
For some reason, gcc or gcovr do not appreciate intermediate gcda/gcno
files being transferred between CI runners. Ensure to rebuild the
tree so that these are freshly created.
Fixes the wonky coverage reports seen lately, as individual test
runs had these fluctuations that made them report as little as 10%
covered, quite far from the more accurate ~77% we get in the correct
runs.
|
| |\
| |
| |
| |
| | |
tests: Fix libtracker-sparql/tracker-serialize-test on macOS
See merge request GNOME/tracker!502
|
| |/
|
|
|
|
| |
echo -n is not portable and most notably it is not implemented by the
bultin echo in the old version of bash used to implement /bin/sh on
macOS. Use printf to supprtess the newline character.
|
| |\
| |
| |
| |
| |
| |
| | |
libtracker-sparql: Use .so suffix for modules on all platforms
Closes #357
See merge request GNOME/tracker!499
|
| |/
|
|
|
|
|
|
|
| |
This is what GModule expects on Unix-like systems, including macOS.
However, meson uses the .dylib suffix by default in the latter case.
The current build definition would not work on Windows, but there are
many other things that would be required to port Tracker there.
Fixes: #357.
|
| | |
|
| |\
| |
| |
| |
| | |
libtracker-common: Do not miss subsecond info printing iso8601 dates
See merge request GNOME/tracker!496
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used %T as a shortcut to print times, but that translates to %H:%M:%S
and misses subsecond information. To avoid that, check whether the passed
GDateTime contains subsecond information and resort to %H:%M:%S.%f in that
case.
Since we prefer shorter iso8601 strings for storage purposes, combine
this handling with the existing paths for timezone information, so iso8601
strings that don't need either can cut down those extra chars.
Fixes subsecond information being lost on database inserts, and possibly
other date comparison/printing misbehaviors.
|
| |\
| |
| |
| |
| | |
Add more tests
See merge request GNOME/tracker!495
|
| | |
| |
| |
| | |
Add tests for column names, and value types.
|
| | |
| |
| |
| |
| | |
Test all corners in graph lookups, and whether visibility changes
accordingly with graph modifications.
|
| | | |
|
| | | |
|
