| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
We were doing an unnecessary intltool-merge step for the file
org.freedesktop.Tracker1.service while failing to do the necessary
configuration substitution. Oops.
|
|\
| |
| |
| | |
See: https://gitlab.gnome.org/GNOME/tracker/merge_requests/13
|
|/
|
|
|
| |
It causes tracker to fail to build on FreeBSD because python is usually
installed in a different prefix, such as /usr/local, on FreeBSD.
|
| |
|
| |
|
|\
| |
| |
| | |
See https://gitlab.gnome.org/GNOME/tracker/merge_requests/12
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Creating a single query for all values to delete can only work if
all values have a match. As soon as a value is already missing,
the query would just bail out as there's no real match.
We want to delete every value individually regardless of other
properties, so decompose the single delete into multiple individual
deletes.
Fixes "Unable to insert multiple values for subject..." warnings
as the insertion queries would rely on single-valued properties being
cleared beforehand.
https://gitlab.gnome.org/GNOME/tracker/issues/28
Closes: #28
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
This test tries to do a pretty dumb DOS on tracker-store for 2s,
so it frequently gets kicked itself from the session bus. Presumably
we don't need it to go that far in testing query cancellation, so
limit the thing to a bunch of queries.
|
| |
|
|
|
|
| |
Fixes: #11
|
| |
|
|\ |
|
| |
| |
| |
| |
| | |
We just used to catch Tracker.Error, so all other errors would
end up propagated upwards.
|
| |
| |
| |
| |
| | |
Otherwise we try to do stuff with it on finalize() that counts on
it being initialized.
|
| |
| |
| |
| |
| |
| | |
This is useless as the "writable" interface is 1) still readonly,
2) unused, and 3) No updates shall ever happen on it, so no need for
the WAL hook.
|
|/
|
|
|
|
| |
Underneath the branch we check for the DB manager being created
as readonly or not. We are not erroring out properly with this
check here.
|
| |
|
| |
|
|
|
|
|
|
| |
Supersedes 2.0.5 (to be ignored). The previous release introduced new
API to let TrackerResource output JSON-LD, so this warrants a minor
version bump as per semantic versioning.
|
| |
|
|
|
|
|
|
| |
Hook up properly the test-bus-query-cancellation functional test in
autotools, and add missing files to be able to build from tarballs with
meson.
|
|
|
|
|
|
| |
This functionality is alive and well in the tracker-miners.git fork of
this code, and has seen lots of fixes. Rather than let this version get
out of sync, let's remove it until something actually needs it.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before commit 68381c1dd, ensure_parents() would stop before the indexing
root in the assumption that it was already notified upon, that commit made
it so those folders are ensured to be notified too.
This internal behavioral change is normally evened out by TrackerMinerFS,
but shows at the tests for the internal TrackerFileNotifier object as
there is nothing there to set the IRI for those files.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It is not even clear this is possible in real life cases, however the
standalone tracker-file-notifier tests fall into this (due to IRI not being
ever set, still this is an async op). In the case of 2 consecutive CREATED
events on the same file, it would be dealt with in TrackerMinerFS as CREATED+
UPDATED. This was already harmless, but we can do better and swallow one of
such events.
|
| |
| |
| |
| |
| |
| | |
This is an internal header, so we don't need pointing to the general
tracker-data.h header. Fixes build from scratch on meson as some files
pulled from there are unexpectedly in the build directory.
|
| |
| |
| |
| |
| | |
There is no point in doing WAL checkpoints from a readonly connection, so
avoid it altogether.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On stress situations (tests/functional-tests/ipc/test-bus-query-cancellation
is known to trigger this) there may be too many opened FDs all around (dbus
related, fds passed for resultsets, DB connections, ...) to keep it all
together.
In those cases, we may attempt to create an extra interface to cater for
the incoming request, but it will just fail underneath us. In those cases
it is preferrable to fetch a connection from the pool and have it shared
across threads than tripping into critical warnings and undefined behavior.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of the lower level TrackerDataManager object directly.
The only additional thing that tracker-store does is signal
emission for writeback and GraphUpdated, the internal
TrackerDataManager object is still accessed to implement those
features. This makes libtracker-direct the only place where
queries/updates are queued, performed and dispatched.
There's other indirect benefit from this, update queue handling
no longer needs to hit the main thread in order to schedule the
next update. Besides the very unlikely thread contention situations
described in previous commits, this should maximize throughput
of the updates queue.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that we don't need upper layers' information to find out the
right CommitType, push this call down together with the handling
of the insert/delete/rollback callbacks.
One particularity is that the commit callbacks will now be called
from within the update thread, just like all the other callbacks.
And this is fine, with all the preparation work from the previous
commits.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Move this out of the Resources object, which is basically a view
of the internal Store object. All event accounting and signaling
is now performed by the Store object, to which the Resources
DBus object connects to in order to implement GraphUpdated and
Writeback signals.
Only one handler of these events is possible at the moment, would
be nice to consider doing something marginally better on the
Steroids interface at some point, at least wrt the amount of data
sent through the bus.
Instead of trying to schedule the timeout across threads (the
TrackerData hooks run in the thread performing the updates, and
we want signaling done from the main/dbus thread), the code now
just sets up a timeout on the main thread that keeps running as
long as there are pending updates. When the task for the last
batched update returns, it will be safe for the timeout to do
signaling one last time and turn itself down, all of this happening
in the main thread.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Just like with ready GraphUpdated events, this will be potentially accessed
by both the thread performing updates, and the thread doing the DBus
dispatching and signaling.
Just like there, the chances of contention are rather low, since emission
is checked just once per second by default.
|
| |
| |
| |
| | |
Purely cosmetic.
|
| |
| |
| |
| |
| |
| | |
Instead of doing get_ready() and then reset_ready(), just give
ownership of the events hashtable on get_ready() while resetting
the internal one.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While the pending data and event counter are only accessed by
the updates thread, the ready events will be potentially accessed
by both the updates and the dbus thread.
That said, chances of locking will be minimal, since the
get_pending() call only happens once a second (by default) or after
the pending buffer grew big enough.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Triggering those on insert/delete callbacks isn't right for two reasons:
there could still be a rollback of the just notified data, and it's done
from the wrong thread (the one performing updates instead of the main
thread).
To fix the first, only call this from the commit hook, we can only notify
of data that was successfully stored. To fix the second, do the call on
an idle that will ensure the main thread running the main loop and doing
the DBus dispatching is the one handling the actual emission. At the
moment the commit hook is actually executed on that same thread, but that
won't stay as-is.
|
| |
| |
| |
| |
| |
| |
| | |
This is solely used by tracker-store to keep the backlog of pending
GraphUpdated events. This event tracking can move to tracker-store
itself, implemented atop libtracker-data's insert/delete/commit/rollback
callbacks.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This basically exists to allow deferring GraphUpdated signals
while there's pending batch updates. This is arguably wrong,
the priorities should totally affect the order in which updates
are processed, but for the sake of interactivity once the data
is in the database it makes sense to let the users know ASAP.
Now all commits shall set up a timer for GraphUpdated emission
is none is set yet.
|
| |
| |
| |
| | |
This will flush all updates and trigger the WAL hook.
|
| |
| |
| |
| |
| |
| | |
This will be useful for tracker-store, and the flags that make sense there
don't make as much sense to add to the public TrackerSparqlConnectionFlags
set.
|
| |
| |
| |
| |
| | |
It's unused and unhandled. As the TrackerDBManager type is internal
API, just remove the flag and shuffle the numbers.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This will make internal users able to access all the gory details
that TrackerDataManager has to offer. Will help deduplicate code
in tracker-store that is essentially the same than this.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In today's chapter of gratuituous rewrites. The instigator of this
rewrite is vala's bug https://bugzilla.gnome.org/show_bug.cgi?id=789249.
One might argue that bugs are bugs and eventually get fixed, but there's
two things that make me think it won't happen soon:
- Vala behavior of possibly iterating the main loop from the async task
until the task is complete is very much deliberate in order to support
the Generator pattern without a main loop, as seen at:
https://wiki.gnome.org/Projects/Vala/AsyncSamples#Generator_example
- OTOH, glib docs specify that a GAsyncReadyCallback must happen at a
later iteration of the main context, presumably to ensure the task
is not finished before the async function dispatching the task returns.
This is precisely what trips Vala into starting the same task again.
I don't see either changing anytime soon, and in the mean time Tracker
is largely affected by it, both in perceived bugs (All those nie:url
constraint warnings out of the blue had a reason, this) and in real bugs
(It's sometimes attempting to insert things twice, and it may even succeed
if the query does not break any cardinality/unique constraints). This
affects Tracker in too fundamental ways to just shrug it away, unlike the
Vala code this C/glib code works just as it looks.
Now about the code... It's a pretty boring rewrite, there's a thread pool
to dispatch select queries, and a single exclusive thread to handle updates.
The WAL hook can possibly use an additional thread to perform non-blocking
writes. All very much alike the older code.
Future commits will make tracker-store use this connection implementation,
so there's only this piece of code handling SPARQL updates.
|
|\
| |
| |
| | |
See https://gitlab.gnome.org/GNOME/tracker/merge_requests/9
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TrackerFileNotifier signals need to be emitted in a heirarchical
order. If we have this directory heirarchy...
test-monitored/
test-monitored/file1.txt
...we must always emit ::file-created for 'test-monitored/' before we emit
::file-created for 'test-monitored/file1.txt'.
The tracker_file_notifier_ensure_parents() function ensures that we do
this, but it would previously not work correctly in situations where
'test-monitored/' was a configured indexing root, rather than a
subdirectory of one of the roots.
This was causing the tracker-miners functional tests to randomly fail
with errors such as this:
** (tracker-miner-fs:18181): WARNING **: 16:01:00.461: Parent 'file:///home/sam/tracker-tests/tmpDSmsQI/test-monitored' not indexed yet
This is presumably a regression from 2e2dd4f5dc650aefa4b7188cf1a612b2d27f84ba.
|