summaryrefslogtreecommitdiff
path: root/src/libtracker-sparql/tracker-connection.h
Commit message (Collapse)AuthorAgeFilesLines
* libtracker-sparql: Deprecate tracker_sparql_connection_update_blank*()Carlos Garnacho2023-01-111-3/+3
| | | | | | | | | | | | | | | | | | Per the spec (https://www.w3.org/TR/sparql11-query/#BGPsparqlBNodes): Since SPARQL treats blank node identifiers in a results format document as scoped to the document, they cannot be understood as identifying nodes in the active graph of the dataset. This is precisely what tracker_sparql_connection_update_blank() (and async variant) are doing. While that works given the interpretation of blank nodes in a TrackerSparqlConnection with default flags, this is precisely what TRACKER_SPARQL_CONNECTION_FLAGS_ANONYMOUS_BNODES implements, and at best it is not great to advise this inconsistency as public API. It is best to deprecate this set of functions, any user should devise their own IRI generation scheme, instead of relying on blank nodes being sort of one.
* libtracker-sparql: Add public API for update TrackerSparqlStatementsCarlos Garnacho2022-12-241-0/+7
|
* libtracker-sparql: Move enum definitionCarlos Garnacho2022-07-071-6/+1
| | | | | | This will be used from more public headers than the connection's, and it's easier to move to a separate header than shuffling header dependencies so other users pull tracker-connection.h
* libtracker-sparql: Add public deserialization APICarlos Garnacho2022-06-301-0/+24
| | | | | | | | | This API takes a GInputStream containing RDF data (loaded from a file, obtained from tracker_sparql_connection_serialize on another connection, ...) and loads it into the TrackerSparqlConnection. So far it's an empty stub, implementations will be added in direct and dbus connections.
* libtracker-sparql: Add tracker_sparql_connection_map_connection()Carlos Garnacho2022-02-101-0/+5
| | | | | | | | | | | This API call allows hooking up a local TrackerSparqlConnection into another, so it is possible to access other local connections from one of them. This happens via the SERVICE SPARQL syntax, using special local:$handle_name URIs. This may be useful if there is data with different relevance (e.g. cache vs persistent) that the application is interested in maintaining separately, but query altogether.
* libtracker-sparql: Add TrackerSerializeFlags argument to serialization APICarlos Garnacho2022-02-041-0/+5
| | | | | This is currently unused, but might be used for future expansion points (e.g. hint the desire for pretty RDF)
* libtracker-sparql: Support serialization to Trig formatCarlos Garnacho2022-02-041-0/+1
| | | | | | This format is similar to turtle, but allows keeping graph information. It might be more convenient for exporting/importing sometimes, so support serializing to this format.
* libtracker-sparql: Add tracker_sparql_connection_serialize_async() APICarlos Garnacho2022-02-041-0/+17
| | | | | | This new call serializes a DESCRIBE or CONSTRUCT query into one of the supported RDF formats. This may be useful in a number of situations, such as data exporting, and bulk migrations.
* libtracker-sparql: Add enum value for anonymous bnodesCarlos Garnacho2021-12-121-0/+3
| | | | | | | This is a default behavior of SPARQL that we deviate from. Add a new TrackerSparqlConnectionFlags value that will be used to honor this. Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/148
* libtracker-sparql: Add method to create statement from a resource fileCarlos Garnacho2021-11-061-0/+6
| | | | | | | | | | | | | | | | This TrackerSparqlConnection method creates a TrackerSparqlStatement from a query located in a resource path. This could allow a better code/model separation where all Tracker resources are separately editable in the source tree (e.g. distinct per-query .rq files, with syntax highlighting, etc), and still directly available at runtime without further disk reads. There's other nice side effects of this, like having queries nicely indented in logging output (instead of the usual string concatenation in code that makes queries alright to see in the source code, but a mess when logged), or avoiding hard to follow code changes (e.g. mass reindenting) when only query changes are required. Also, queries would be easily readable with the "gresource list/extract" command line tool without looking across the source code.
* Add G_BEGIN/END_DECLS to remaining headers included from tracker-sparql.hPekka Vuorela2021-04-141-0/+4
| | | | Already in some but not all.
* libtracker-sparql: Add tracker_sparql_connection_bus_new_async/finishwip/carlosg/bus-new-asyncCarlos Garnacho2021-03-091-0/+11
| | | | | | | | | | | | The bus connection started creating a dbus proxy that we did not need to autostart, nor read properties from, so we could initially afford to not have an asynchronous version. But later we added more things on it, like session registration in the portal, and pings to check for direct access permissions within a possible sandbox. It now makes sense to have that async variant, so add one.
* libtracker-sparql: Add TrackerBatch APICarlos Garnacho2020-11-271-0/+4
| | | | | This API allows pushing a series of update commands, in either SPARQL or TrackerResource form. This is committed as a single transaction.
* libtracker-sparql: Add tracker_sparql_connection_update_resource() callCarlos Garnacho2020-11-271-0/+18
| | | | | And an async variant. This takes a TrackerResource and pushes it directly to the DB.
* libtracker-sparql: Don't expose internal db interface errorsSam Thursfield2020-08-101-52/+1
| | | | | | | | | | | | | | | | We should not return TrackerDBInterfaceError, from the internal libtracker-data library, from public functions in libtracker-sparql. This problem is noticable as we register D-Bus error codes only for the public TrackerSparqlError type. Before, apps would show error messages like this: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._tracker_2ddb_2dinterface_2derror_2dquark.Code0: example error message After this patch, the error is: GDBus.Error:org.freedesktop.Tracker.Error.QueryFailed: example error message
* libtracker-sparql: Drop priority argument from async functionsCarlos Garnacho2020-06-191-3/+0
| | | | Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/218
* libtracker-sparql: Drop priority argument from sync functionsCarlos Garnacho2020-06-191-2/+0
| | | | Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/218
* libtracker-sparql: Drop notifier flagsCarlos Garnacho2020-06-181-2/+1
| | | | | | | | 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: Map GError codes to DBus error codesSam Thursfield2020-05-011-0/+17
| | | | | | | | | | DBus errors before: gi.repository.GLib.GError: tracker-sparql-error-quark: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._tracker_2dsparql_2derror_2dquark.Code0: Parser error at byte 0: Expected Query (0) DBus errors now: gi.repository.GLib.GError: tracker-sparql-error-quark: GDBus.Error:org.freedesktop.Tracker.Error.Parse: Parser error at byte 0: Expected Query (0)
* libtracker-sparql: Raise an error if no ontology is passedSam Thursfield2020-04-291-1/+2
| | | | | | Since a0efd1972b122d0a2 it was possible to crash by passing a NULL ontology path to tracker_sparql_connection_new(). Now we raise an error instead.
* libtracker-sparql: Add tracker_sparql_connection_close_async/finishCarlos Garnacho2020-02-171-0/+11
| | | | | Since it may be "expensive" with a big amount of pending requests, add an async variant so it doesn't have to block the main loop.
* libtracker-sparql: Add TrackerSparqlConnectionFlags to configure FTSCarlos Garnacho2020-02-171-2/+10
| | | | | | | | | | Those flags are based on the FTS gschema settings, although kind of reduced. The flags are propagated down the FTS parser, and stored/ checked as main DB metadata, so we catch changes in those and rebuild FTS tokens accordingly. Readonly connections will not be able to issue any changes, and will go with the settings as stored in the metadata table.
* libtracker-sparql: Some documentation improvements/fixesCarlos Garnacho2020-02-171-0/+7
|
* libtracker-sparql: Make class structs privateCarlos Garnacho2020-02-171-65/+0
| | | | | | 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: Add define to export library functionsCarlos Garnacho2020-02-171-2/+25
| | | | | | | | | | And get rid of the map file. This allows us to selectively make API public, so we no longer need it, nor regexps. Also, add the beginning of TRACKER_AVAILABLE_IN_* defines, so we can help with testing minor version changes, add deprecation warnings, etc. So far we're heading towards 3.0, all public API started using this with TRACKER_AVAILABLE_IN_ALL, since we're bumping major version.
* libtracker-sparql: Reimplement public API in CCarlos Garnacho2020-02-171-0/+235
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.
View Lorry Controller Status