summaryrefslogtreecommitdiff
path: root/src/libtracker-sparql/tracker-notifier.c
Commit message (Collapse)AuthorAgeFilesLines
* libtracker-sparql: Sanitize "Since" tagswip/carlosg/batches-and-resourcesCarlos Garnacho2020-11-271-6/+0
| | | | Remove all pre-3.0 ones, and drop API indexes prior to that.
* tracker-notifier: Fix tracker_notifier_signal_subscribe annotationwip/jfelder/tracker-notifier-annotationJean Felder2020-11-121-2/+2
|
* libtracker-sparql: Batch TrackerNotifier queriesCarlos Garnacho2020-10-181-2/+27
| | | | | | | | | | | | If we happen to get a high enough amount of updates, batched changes accumulate, all querying for the additional information. This accumulation of the same query leads at best to compiling new statements (as the cached one is already in use). At worst, it leads to the creation of a new TrackerDBInterface, with the initialization cost involved. Serializing this work, we're more likely to reuse a TrackerDBInterface and a pre-compiled statement from previous runs.
* libtracker-sparql: Query notifier data in batchesCarlos Garnacho2020-08-101-28/+36
| | | | | | | | | | | | | | | | We have limits with the services table, and other limits on the number of parameters higher up. We shouldn't be doing queries with an arbitrary number of those. Limit the batch size in queries for extra TrackerNotifier data, and adapt code to maybe do extra queries for a single event batch. As it is now possible that we are initiating queries on a fresh new TrackerNotifierEventCache when an old one is still being processed, and this happens from different threads (the update thread for the initial one triggered from commit hooks, the main context thread for later async processing), protect the statements execution with a mutex, as binding arguments for execution is not thread safe.
* libtracker-sparql: Update TrackerNotifier docsSam Thursfield2020-07-241-24/+4
| | | | These were outdated since e1c6966a9a941fc61db3b32e5eee31f8512e2462
* libtracker-sparql: Handle notifier query cursor in a threadCarlos Garnacho2020-06-271-23/+63
| | | | | Take this out of the main thread, so we don't block it when dealing with large sets of changes.
* libtracker-sparql: Set up default object path before subscriptionCarlos Garnacho2020-06-271-2/+3
| | | | | | We need this for comparing correctly with the SPARQL bus connection, otherwise we are comparing NULL object path with the default /org/freedesktop/Tracker3/Endpoint
* libtracker-sparql: Fix typoCarlos Garnacho2020-06-271-1/+1
| | | | We want to fetch the class here o\.
* libtracker-sparql: Use more hackish ways to check for local bus notificationsCarlos Garnacho2020-06-251-2/+4
| | | | | | | | | | | Bringing the tracker-bus.h header here is troublesome, since that header is generated later on from vala source code in the build pipeline (first comes this "temporary" libtracker-sparql static library, then bus/direct/remote, then all is merged together into the final library). In order to avoid the possible build issues this may bring, use a more hackish way to check for a TrackerSparqlConnection being a bus one, without requiring an explicit dependency on libtracker-bus at build time.
* libtracker-sparql: Update tracker-bus.h header locationCarlos Garnacho2020-06-221-1/+1
|
* libtracker-sparql: Use TrackerSparqlStatement in TrackerNotifierCarlos Garnacho2020-06-211-45/+115
| | | | | | | | | | Keep one prepared statement for queries on the local connection, plus one prepared statement per DBus subscription. Use the corresponding one when querying URNs for a set of IDs. Since prepared statements have a fixed number of arguments, keep the maximum ever used, and add ID=0 as padding for the unused ones (since they must be bound).
* libtracker-sparql: Add API docs for notifier DBus subscription callsCarlos Garnacho2020-06-211-0/+30
|
* libtracker-sparql: Perform notifier queries on the right serviceCarlos Garnacho2020-06-211-16/+73
| | | | | | | | | | | | We must figure out (and shortcut) the cases where the service matches our own connection one (In the case of a bus TrackerSparqlConnection). In any other case, perform the queries on the same service that issued the GraphUpdated signal. Also ensure we set a coherent "service" argument in the ::events signal for those same connections. Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/227
* libtracker-sparql: Add object_path arg to DBus subscription notifier APICarlos Garnacho2020-06-211-4/+25
| | | | | This API complements the tracker_sparql_connection_bus_new() API allowing to provide an object path. If one side allows this, the other should too.
* libtracker-sparql: Drop notifier flagsCarlos Garnacho2020-06-181-38/+3
| | | | | | | | URNs are the preferred way to identify resources in a tracker store, don't treat them as an afterthought here and query the URNs right away. Drop the flags argument entirely as it becomes unneeded, any further information cannot be inferred and should be performed by the user.
* libtracker-sparql: Cache service name along with the subscriptionCarlos Garnacho2020-04-051-12/+16
| | | | | | | The signal callback will not contain the well-known name in the sender argument, but the internal bus name made up for the connection. Cache the service name along in the TrackerNotifierSubscription, so we can retrieve it in the callback without name lookups.
* libtracker-sparql: Update endpoint interface/path to Tracker3Carlos Garnacho2020-04-051-2/+2
| | | | Use a tracker version consistent with our current API version.
* libtracker-sparql: Cancel info query on notifier finalizationCarlos Garnacho2020-02-171-2/+20
| | | | | | We are indirectly safe here as the event cache holds a ref to the notifier, but seems sensible to ensure that TrackerNotifier finalization would result in async queries bailing out.
* libtracker-sparql: Always emit TrackerNotifier::events on an idleCarlos Garnacho2020-02-171-6/+17
| | | | | | This ensures the callback will be dispatched outside of the updates thread, and presumably into the main application thread/main context. Also makes this function dependent on a main loop.
* libtracker-sparql: Correct doc commentCarlos Garnacho2020-02-171-2/+2
|
* libtracker-sparql: Add GType for TrackerNotifierEventCarlos Garnacho2020-02-171-0/+5
| | | | In order to help bindings.
* libtracker-sparql: Make TrackerNotifier queries asynchronousCarlos Garnacho2020-02-171-15/+35
| | | | | | | | | Synchronous queries are very untimely here, since the events are handled within TrackerDirectConnection mutex, triggering deadlocks here. Doing the queries asynchronously defers this to a thread pool, so the mutex will be contended from 2 separate threads, if at all.
* libtracker-sparql: Prepare for doing asynchronous queriesCarlos Garnacho2020-02-171-32/+31
| | | | | | Operate on the cached elements as they are stored in the sequence and the cache struct, we will see it being passed along asynchronous queries soon.
* libtracker-sparql: Remove needless TrackerNotifier checkCarlos Garnacho2020-02-171-8/+2
| | | | | We now forward inserts and deletes as is, and attempt no event coalescing. This path with event_type == -1 is unused.
* libtracker-sparql: Make class structs privateCarlos Garnacho2020-02-171-0/+1
| | | | | | No object in the public API is meant to be subclassed, hide the class definitions so we have room to extend those at will in the future.
* libtracker-sparql: Reimplement public API in CCarlos Garnacho2020-02-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is risky and clunky to have API/ABI in control of a transpiler like Vala is. Examples are: - Defining the abstract classes in vala necessarily exports these *_construct() functions, which are 100% useless as public API since no subclassing of Tracker objects is whatsoever allowed outside of Tracker. - While on the *_construct() functions topic, adding a constructor like tracker_sparql_connetion_new() somehow made valac stop exporting one for TrackerSparqlConnection. The warnings are somehow eaten when compiling the resulting C code, but hell breaks loose when the C compiler assumes an int return value (because it can't know better) but the constructor has a pointer-sized return value. Since those functions are exported, this change sneakily involves an ABI break too. - Even though we want some properties to be construct-only, vala will automatically export setter functions for those. This adds API like tracker_sparql_statement_set_connection() that can only break things if ever called. - The --abi-stability valac toggle was added too late for Tracker to use it. We could use 3.0 as an excuse to turn it on, but that doesn't magically fix the other points. - Vala doesn't allow us to be explicit wrt the exported functions (eg. through extern). We do resort to a .map file, but that's prone to errors and hairy to maintain. We still use vala at places for internal code, but I can't bring myself to think it's a good idea to keep vala in charge of our public API and ABI.
* libtracker-sparql: Proxy database changes through endpoint GraphUpdatedCarlos Garnacho2020-02-171-2/+2
| | | | | This internally connects a TrackerNotifier, which ::event signal is serialized into the DBus signal we emit.
* libtracker-sparql: Export TrackerNotifierEventCache for implementationsCarlos Garnacho2020-02-171-16/+27
| | | | | This API is private, expected to be used across implementations of TrackerSparqlConnection/TrackerNotifier.
* libtracker-sparql: Change arguments in TrackerNotifier::events signalCarlos Garnacho2020-02-171-41/+20
| | | | | | | | We now emit service and graph as first arguments, and drop the rdf:type API, following the GraphUpdated signal from the Endpoint DBus interface. This makes the object and dbus signals match closer, enough for it to be straightforward to map one to the other.
* libtracker-sparql: Make TrackerSparqlConnection generate TrackerNotifiersCarlos Garnacho2020-02-171-127/+17
| | | | | | There's now a tracker_sparql_connection_create_notifier() vmethod that subclasses may implement. This makes the relation between a notifier and a sparql connection direct, instead of completely undefined.
* libtracker-sparql: Add methods to subscribe to GraphUpdated from servicesCarlos Garnacho2020-02-171-38/+85
| | | | | | | | | | We may set up the TrackerNotifier so it makes sense for the used connection, but can't cater for the other services that an user might be interested in. Add some methods so it's possible to tell the TrackerNotifier which services to listen to. As there's no longer a single default GraphUpdated source, TrackerNotifier no longer sets up one by default.
* libtracker-sparql: Change TrackerNotifier to subscribe to Endpoint eventsCarlos Garnacho2020-02-171-112/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We so far settle on a sa{ii} signature for the endpoint's GraphUpdated signal. The DBus name of the emitter itself holds the endpoint name, the first string argument holds the graph, and the array holds pairs of event hints (created/updated/deleted) and resource IDs. This has some notable differences with the old GraphUpdated signature: - It used to notify insertions and deletions for all properties. That much granularity made the size of the passed variant data considerably bigger to little gain, as subcribers (TrackerNotifier first) do not track individual property changes except for rdf:type, which determines the existence of a resource. All other property changes are simply "updates". The new DBus signature takes this simplification closer to the root, providing high level hints about what happened per resource. This reduces a whole array of 4 integers to just 2 integers (no array) per resource. This should slim down the message size by a fair amount. - The old signal used to be all about rdf:types, it was the first argument in the signature precisely to allow arg0 filtering. With resources being able to be multiple things at the same time, and being able to be different things across different graphs, this split proves confusing. A single property change may be emitted multiple times, and might even result in different actions depending on the rdf:type it's notified through (eg. deleting the rdf:type itself). The new signal signature handles resources globally within the graph. When they gain the first rdf:type that must be notified they will be created, and after deleting the last such rdf:type will delete the resource. Everything in between are updates.
* libtracker-sparql: Simplify URN queries in TrackerNotifierCarlos Garnacho2020-02-171-94/+6
| | | | | We no longer need to distinguish deleted events from the others, we can query the ID/URN pairs in a generic manner.
* libtracker-sparql: Make TrackerNotifierEventCache more standaloneCarlos Garnacho2020-02-171-52/+54
| | | | | | Instead of just caching the events, it can now also flush them. This will make the object useful to be exported, and hooked through different ways internally. In future commits though.
* libtracker-sparql: Drop TRACKER_NOTIFIER_FLAG_QUERY_LOCATIONCarlos Garnacho2020-02-171-39/+7
| | | | | | | | | | This is very tied to nie:url and the Nepomuk ontology, plus it has all sorts of oddities with DELETE events, since it can't be queried at that time. Sounds like something the caller can handle better than we do, as in most cases it still doesnt' drop the need for additional queries in response to notifier events.
* libtracker-sparql: Drop TRACKER_NOTIFIER_FLAG_NOTIFY_UNEXTRACTEDCarlos Garnacho2020-02-171-45/+2
| | | | | | | The nie:dataSource trick we employ here is highly dependent on tracker-miners implementation, and the whole concept of "unextracted". Drop this flag and make it happen by default, the number of updates we get will be dependent on the service we listen to.
* libtracker-common: Make TrackerDomainOntology totally not an objectCarlos Garnacho2019-07-311-1/+1
| | | | | | | | | Hopefully the last chapter in the "make libtracker-common static" saga... Turn this object into a refcounted struct, as we still may end up with multiple copies of libtracker-common in libtracker-miner, through libtracker-sparql.so and directly as it also uses libtracker-common. This resulted in assertions when trying to register the same type name twice.
* docs: Turn URI reference into a proper linkSam Thursfield2019-03-301-1/+1
| | | | | | This fixes the following warning while building the docs: html/TrackerNotifier.html:363: warning: no link for: "Audio" -> (<span class="type">Audio</span>).
* libtracker-sparql: Check for null pointers in finalize()wip/ernestask/43Ernestas Kulik2018-10-061-4/+9
| | | | | | | tracker_notifier_finalize() may accidentally stumble upon a null pointer or two, throwing warnings and making Nautilus CI pipelines fail. Related: https://gitlab.gnome.org/GNOME/tracker/issues/43
* Revert "Revert "Add tracker_sparql_connection_get/set_dbus_connection()""Carlos Garnacho2018-09-091-1/+3
| | | | | | This reverts commit df768eff07c817924f431ece0d09a24edab74de2. Now that we branched for tracker-2.2, reintroduce this new API.
* Revert "Add tracker_sparql_connection_get/set_dbus_connection()"Carlos Garnacho2018-08-301-3/+1
| | | | | | | This reverts commit eb24ea93bc550934d15223d002b490143e604921. This is an interesting feature, but not a good timing. Punt for 2.2.x that will happen after 3.30.
* Merge branch 'sam/domain-rules-outside-usr'Sam Thursfield2018-08-161-1/+1
|\ | | | | | | See https://gitlab.gnome.org/GNOME/tracker/merge_requests/14
| * tracker_domain_ontology_get_domain() should return only the domain nameSam Thursfield2018-08-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should be consistent about what the name of a Tracker domain actually is. In the domain rule we specify Domain=org.freedesktop (for the default rule) or Domain=org.example.App (for a custom domain). But internally tracker_domain_ontology_get_domain() would return org.freedesktop.Tracker1 or org.example.App.Tracker1, i.e. the domain name now has '.Tracker1' appended. This does make sense in most cases, but it means there's no way to get the actual name of the domain from a TrackerDomainOntology object. This commit changes the existing function to not append '.Tracker1' in the value it returns, which means that function can now be used to get the base name of the domain. The assumption is that callers are normally appending stuff to this base name anyway so it's not much extra effect to also append the '.Tracker1' component if needed. libtracker-common is internal to Tracker so this doesn't constitute a public API break.
* | Add tracker_sparql_connection_get/set_dbus_connection()sam/tracker-sparql-connection-set-dbus-connectionSam Thursfield2018-08-111-1/+3
|/ | | | | | | | | | | | Currently it's only possible to open a TrackerSparqlConnection to an instance of Tracker that is running on the session-wide message bus. There are use cases for running the Tracker daemons on a private session bus though. In fact it's necessary to do this if you want to set up a custom domain without having to become root and create .service files in /usr/share/dbus-1/services. It would also be useful for the functional-tests to be able to use libtracker-sparql instead of having to talk directly to Tracker's D-Bus API.
* libtracker-sparql: Be more careful about integer sizesDebarshi Ray2018-01-231-3/+3
| | | | | | | | The GVariant type string "i" refers to a signed 32-bit integer. Therefore, gint32 is a much safer bet than gint, whose size is not guaranteed across all platforms. https://bugzilla.gnome.org/show_bug.cgi?id=792301
* libtracker-sparql: Introspection fix for tracker_notifier_new()Sam Thursfield2017-09-291-2/+2
| | | | The tracker_notifier_new() function allows NULL for 'classes'.
* libtracker-sparql: Fix introspection for Tracker.Notifier.new()Sam Thursfield2017-09-221-1/+2
| | | | The 'classes' parameter wasn't annotated correctly.
* libtracker-sparql: Fix horrible confusion with G_GINT64_FORMATCarlos Garnacho2017-07-111-5/+5
| | | | | The "d" is already implied there, not for us to add. Let's pretend this never happened...
* libtracker-sparql: Make TrackerNotifier check GraphUpdated from the domainCarlos Garnacho2017-06-291-1/+13
| | | | It must listen to the signal from the right tracker-store instance.
* libtracker-sparql: Use correct printf format specifiers for gint64Sam Thursfield2017-03-211-6/+7
| | | | | Sadly the correct format is different on 32bit and 64bit systems so we have to use the unweildy G_GINT64_FORMAT macro.
View Lorry Controller Status