summaryrefslogtreecommitdiff
path: root/src/libtracker-data/tracker-data-manager.c
Commit message (Collapse)AuthorAgeFilesLines
* Domain-ontologies: allow more flexibility on locations. Example:domain-ontologiesPhilip Van Hoof2017-01-301-40/+73
| | | | | | | | | | | | /opt/tracker/share# cat tracker/domain-ontologies/test.rule [DomainOntology] DataLocation=%HOME%/.cache/test/data CacheLocation=%HOME%/.cache/test/cache OntologyLocation=%SHAREDIR%/tracker/ontologies Domain=test DBusPath=/test OntologyName=test
* Add cache location to db manager and data managerPhilip Van Hoof2017-01-291-12/+25
|
* Allow loading domain ontology from .desktop filePhilip Van Hoof2017-01-281-12/+12
|
* libtracker-data, tracker-store: domain specific ontologiesPhilip Van Hoof2017-01-281-0/+3
|
* Whitespace fixesPhilip Van Hoof2017-01-281-4/+4
|
* libtracker-data: tracker-store: Initial infrastructure to support domainPhilip Van Hoof2017-01-271-5/+30
| | | | specific ontologies
* libtracker-data: Propagate "locale mismatch" error from locale_changed()Carlos Garnacho2016-10-191-1/+1
| | | | | | | | | | | | And set the differing locales in the error message. Errors here are mainly due to 1) inconsistent locales, specifically the client running with a different locale than tracker-store, and 2) faulty apps that don't call setlocale() as appropriate. We already used to warn when locales differ, but the message wasn't that useful. Including the differing locales helps narrow down the issue. This error is mainly visible in the libtracker-direct backend, tracker-store shall handle locale changes on (re)start.
* libtracker-data: Fix typoCarlos Garnacho2016-10-091-1/+1
|
* libtracker-data: Fix pointer sign warningsSam Thursfield2016-06-241-4/+4
|
* Update to FTS5Carlos Garnacho2016-03-011-9/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our old stale copy of the FTS3/4 module is now deleted, replaced by a shinier FTS5 embedded module. If at configure time we detect that SQLite doesn't offer the FTS5 module, we will load our own, just as we used to do with FTS4. FTS5 brings a few differences in the ways it's meant to be extended, the tokenizer has been updated to cope with the differences. Also, FTS5 offers no offsets() builtin function, nor matchinfo() which we used to implement ranking. It offers though ways to implement additional functions, and builtin rank support which can be tweaked to achieve the same functional results than we did. Other than that, the ways to interact with the FTS virtual table are roughly similar to those in FTS4, insertions and deletions have been updated to do things the FTS5 way. Since it's not worth to bump the database format (data is reproducted from the journal, so we drop some embedded data such as nie:plainTextContent), the nco:hobby property has been modified to no longer be fulltext indexed, AFAIK there's no users ever setting/ accessing that, and the FTS properties change will trigger the regeneration of the FTS view and virtual tables, resulting in a seamless update to FTS5. However, we don't leave completely unscathed from the fts3_tokenizer() change. Since the older FTS3/4 tokenizer is not registered, we can't just drop the older FTS table. So it is left dangling and never accessed again, in favor of the newer fts5 table. This is obviously not a problem when creating the database from scratch. In the way, a few bugs were found. per-property weights in ranking were being given in a scrambled way (although stable across database generations). And deletion of FTS properties (or entire rows) could result in the tokens not being fully removed from the FTS table, resulting in confused searches. These are now fixed. Impact to users of tracker should be none. All the FTS Sparql-to-SQL translation has been updated to just use FTS5 syntax and tables.
* libtracker-data: Handle tracker:fulltextIndexed changesCarlos Garnacho2016-03-011-28/+14
| | | | | | | | We no longer have a reason to deem this change incompatible. Since no actual text is stored in the FTS tables, and it merely updates its tokenization info from the original class tables, we can just drop this info and reconstruct at will. So there's no longer need to consider tracker:fulltextIndexed changes as incompatible.
* libtracker-data: Rework ontology_get_fts_properties()Haithem BEN GHORBAL2016-02-151-18/+8
| | | | | All callers require both hashtables, so remove NULL handling for those. Fixes a possible memory leak if fts_properties is NULL.
* Revert "libtracker-data: Clean up stale URIs on startup"Philip Van Hoof2016-01-161-21/+0
| | | | This reverts commit e4a0f7be0c138a733b74413ff7a11a9431c7fe08.
* libtracker-data: Cope for cardinality changes overwriting indicesCarlos Garnacho2015-07-261-0/+6
| | | | | | There's otherwise name collision between the old single-valued index and the new multivalued table. The index for the multivalued table will be created afterwards.
* libtracker-data: Clean up stale URIs on startupCarlos Garnacho2015-07-251-0/+21
| | | | | | | | | | | | | | | | | The Resource table can be left populated with stale resources, in order to avoid these from accumulating, clean these up during startup. This assumes all miners and clients will be educated and will clean up all references to deleted resources (triples of the form {?urn some:prop ?deleted}) at the moment deletes happen, and always during the lifetime of the previous run of tracker-store. If there's sloppy miners/clients that don't fully unlink the resource, or users mess with the lifetime of tracker-store in the middle of such maintenance operations, we will leave such stale values around the database, possibly confusing queries where the predicate is used in the WHERE section. Short of having fully refcounted resources, seems like a minor drawback.
* libtracker-data: Trigger rebuild of FTS tokens on parser changesCarlos Garnacho2015-07-041-0/+20
| | | | | | | | Whenever there's a change in the implementation of our tokenizers, we'll trigger a rebuild of the FTS table. This allows for live updates to our tokenizers without the need to redo the database from scratch. The FTS rebuild is also triggered on locale changes.
* tracker-data-manager: Re-creating tables don't add any property columnCarlos Garnacho2015-03-061-1/+1
| | | | | | | | | | | | | | If, during database update, the migration code chose to create a table from scratch, dumping data from the original one (eg. removing columns for properties that now have maxCardinality>1 and move to their own table), the destination table would be missing virtually all fields. When this happens, in_update differs from in_alter (the former tells whether we're creating the DB from scratch, the latter whether we're altering the original table). As we're actually creating the table from scratch, we must behave as such when dealing with the affected properties. https://bugzilla.gnome.org/show_bug.cgi?id=745737
* data-manager: Account for cardinality=0 on DB migrationCarlos Garnacho2015-02-241-5/+6
| | | | | | | | | If a property changes from maxCardinality 1 to many, the database format is updated to cope with that, but at the time of migrating data, it doesn't account for resources having no elements. In order to avoid constraint errors, those must be skipped. https://bugzilla.gnome.org/show_bug.cgi?id=743727
* Make --disable-tracker-fts compile againPhilip Van Hoof2014-11-301-2/+2
|
* libtracker-common: Moved tracker-ontologies.h into libtracker-sparqlMartyn Russell2014-10-271-64/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | The Namespace has been cleaned up too, all APIs now start with: TRACKER_PREFIX_ or TRACKER_DATASOURCE_ The well known definition for the TrackerMinerFS graph has also been changed to: TRACKER_OWN_GRAPH_URN because it now applies to more than just the TrackerMinerFS, we're using it in: tracker-writeback tracker-miner-apps tracker-miner-user-guides ... libtracker-data It should probably be internal actually.
* Support for nrl:maxCardinality changing from one to manyPhilip Van Hoof2014-09-291-40/+113
|
* libtracker-fts: Fixed memory leak for property_names variableMartyn Russell2014-09-011-1/+8
|
* libtracker-data: getting FTS multivalued properties used unintialised variableMartyn Russell2014-03-061-1/+1
|
* libtracker-data: Make sure we return TRUE/FALSE on success or not for fts initDominique Leuenberger2013-02-261-0/+2
| | | | Fixes GB#693889, E: tracker no-return-in-nonvoid-function tracker-data-manager.c:361
* libtracker-data: Removed tracker:fulltextNoLimitMartyn Russell2013-02-141-50/+5
|
* libtracker-data: Use g_hash_table_unref() not _destroy()Martyn Russell2013-02-041-4/+4
|
* libtracker-data: Use a g_message() for cases where FTS is disabledMartyn Russell2013-02-041-2/+2
|
* Use fts4 external content tables on Tracker FTSCarlos Garnacho2013-02-041-48/+61
| | | | | | | | | | | | | | | | FTS support on Tracker is now implemented using external content support available in sqlite >= 3.7.9 FTS4. FTS tables created this way fetch data from a single table/view, for this purpose an intermediate view has been created to interface with the FTS table. As this view is mainly queried by ID (both when populating the FTS contents, and when querying throught the FTS table), queries are fast enough on it. As FTS indirectly points to the data on the real tables where tracker data is stored, strings themselves are stored only once in the database, so there is no impact in database size when compared to the previous custom FTS code. Performance had little changes too from testing.
* libtracker-data: Fix FTS initializationCarlos Garnacho2013-02-041-2/+2
| | | | | Use a define that actually exists around tracker_fts_init(), which also checked for the inverted value.
* libtracker-data: remove useless FTS functionsCarlos Garnacho2013-02-041-1/+8
| | | | | commit/rollback should happen now with the rest of the operations, and update_init() isn't necessary anymore.
* libtracker-data: Cope with ontology changes in the FTS tableCarlos Garnacho2013-02-041-2/+17
| | | | | If a new property is with tracker:fulltextIndexed, we need to add a new column for it in the FTS table.
* libtracker-data: Create several columns for FTS dataCarlos Garnacho2013-02-041-3/+48
| | | | | there is now one column per ontology property with FTS enabled, the column name is that of the property.
* libtracker-fts: Update to FTS4Carlos Garnacho2013-02-041-0/+6
| | | | | | The code isn't yet feature complete, but cleans up the tracker integration with the FTS module, which means that fts3* files are taken verbatim from sqlite, and are licenced as such.
* libtracker-data: Fix dead code with disabled journalJürg Billeter2012-02-071-2/+2
|
* libtracker-data: Also recreate domain indexes on collation changeJürg Billeter2011-10-281-0/+12
| | | | Fixes NB#286610.
* libtracker-data: Do not consider index recreation failure fatalJürg Billeter2011-09-231-2/+4
| | | | | | Tracker can operate with missing indices. Fixes NB#283501.
* libtracker-data: Drop all indexes before index recreationJürg Billeter2011-09-161-11/+28
| | | | | | | Recreating an index with new collation while indexes with old collation still exist may result in SQLite reporting database corruption. Fixes NB#282541.
* libtracker-data: Make index recreation less verboseJürg Billeter2011-09-161-12/+0
| | | | | fix_indexed already prints the index name before all SQL statements executed, no need to print class and property name in recreate_indexes.
* libtracker-data: Support for removing rdfs:subPropertyOfPhilip Van Hoof2011-09-131-8/+31
| | | | Fixes NB#281335.
* libtracker-data: Detect unsupported ontology change rdfs:subPropertyOfPhilip Van Hoof2011-09-131-4/+80
|
* libtracker-data: Log error message on unsupported ontology changeJürg Billeter2011-09-131-3/+3
|
* libtracker-data: Do not reset database on unsupported ontology changeJürg Billeter2011-09-131-4/+6
| | | | | | If the journal is disabled, do not reset database on unsupported ontology change as this would loose data. Instead, continue operation with old ontology version.
* libtracker-data: Rollback transaction on unsupported ontology changeJürg Billeter2011-09-131-48/+3
| | | | | | This does not make a difference when replaying journal, however, if the journal is disabled, we want to continue using the old ontology if we cannot use the new version.
* libtracker-data: Fix error check for unsupported ontology changeJürg Billeter2011-09-131-3/+9
|
* libtracker-data: Use ontology from database if cache is unavailableJürg Billeter2011-09-011-2/+10
| | | | Fixes NB#279789.
* libtracker-data: Unused variable in case of --disable-journalPhilip Van Hoof2011-07-051-2/+9
|
* libtracker-data: Disable journal with --disable-journalPhilip Van Hoof2011-06-291-0/+43
| | | | Fixes NB#268105.
* libtracker-data: Initialization of db during restore must be handled if failsPhilip Van Hoof2011-06-291-0/+6
| | | | | | In case the initialization of the db fails during the restore of a backup, and only in case of --disable-journal, then should the init fail with an error instead of trying to recreate a clean meta.db
* libtracker-data: Create ontologies.gvdb on startup if necessaryJürg Billeter2011-06-281-4/+9
|
* libtracker-data: Propagate errors from db_get_static_dataJürg Billeter2011-06-281-27/+33
|
View Lorry Controller Status