Connection


Object Hierarchy:

Object hierarchy for Connection

Description:

[ CCode ( type_id = "tracker_sparql_connection_get_type ()" ) ]
[ GIR ( name = "SparqlConnection" ) ]
public abstract class Connection : Object

`TrackerSparqlConnection` holds a connection to a RDF triple store.

This triple store may be of three types:

  • Local to the process, created through [ctor@SparqlConnection.new].
  • A HTTP SPARQL endpoint over the network, created through [ctor@SparqlConnection.remote_new]
  • A DBus SPARQL endpoint owned by another process in the same machine, created through [ctor@SparqlConnection.bus_new]

When creating a local triple store, it is required to give details about its structure. This is done by passing a location to an ontology, see more on how are [ontologies defined](ontologies.html). A local database may be stored in a filesystem location, or it may reside in memory.

A `TrackerSparqlConnection` is private to the calling process, it can be exposed to other hosts/processes via a [class@Endpoint], see [ ctor@EndpointDBus.new] and [ctor@EndpointHttp.new].

When issuing SPARQL queries and updates, it is recommended that these are created through [class@SparqlStatement] to avoid the SPARQL injection class of bugs, see [method@SparqlConnection.query_statement] and [method@SparqlConnection.update_statement]. For SPARQL updates it is also possible to use a "builder" approach to generate RDF data, see [class@Resource]. It is also possible to create [ class@SparqlStatement] objects for SPARQL queries and updates from SPARQL strings embedded in a [struct@Gio.Resource], see [ method@SparqlConnection.load_statement_from_gresource].

To get the best performance, it is recommended that SPARQL updates are clustered through [class@Batch].

`TrackerSparqlConnection` also offers a number of methods for the simple cases, [method@SparqlConnection.query] may be used when there is a SPARQL query string directly available, and the [method@SparqlConnection.update] family of functions may be used for one-off updates. All functions have asynchronous variants.

When a SPARQL query is executed, a [class@SparqlCursor] will be obtained to iterate over the query results.

Depending on the ontology definition, `TrackerSparqlConnection` may emit notifications whenever resources of certain types get insert, modified or deleted from the triple store (see [nrl:notify](nrl-ontology.html#nrl:notify). These notifications can be handled via a [ class@Notifier] obtained with [method@SparqlConnection.create_notifier].

After done with a connection, it is recommended to call [method@SparqlConnection.close] or [method@SparqlConnection.close_async] explicitly to cleanly close the connection and prevent consistency checks on future runs. The triple store connection will be implicitly closed when the `TrackerSparqlConnection` object is disposed.

A `TrackerSparqlConnection` may be used from multiple threads, asynchronous updates are executed sequentially on arrival order, asynchronous queries are dispatched in a thread pool.

If you ever have the need to procedurally compose SPARQL query strings, consider the use of [func@sparql_escape_string] for literal strings and the [func@sparql_escape_uri] family of functions for URIs.


Namespace: Tracker.Sparql

Content:

Static methods:

Creation methods:

Methods:

Inherited Members: