2015-12-17 Carlos Garnacho Release 1.7.1 libtracker-extract: Fix double free We're giving ownership of the GError to the task, no need to free here. libtracker-miner: Fix double free Pass a copy of the error to the GTask, we're freeing our own together with the others in the array afterwards. 2015-12-15 Anders Jonsson Updated Swedish translation 2015-12-13 Matej Urbančič Updated Slovenian translation 2015-12-10 Debarshi Ray libtracker-data: Silence a CRITICAL We shouldn't be passing a NULL string argument to g_regex_match. https://bugzilla.gnome.org/show_bug.cgi?id=759280 2015-12-02 Carlos Garnacho Merge branch 'wip/garnacho/sparql1.1' libtracker-miner: Optimize move operations Instead of creating one delete+insert per file (indirectly) contained in a folder, do it all at once in a DELETE...INSERT...WHERE. We only now need to query and block if we're running a thumbnailer service, which should be most uncommon. This makes the whole update to happen in a much tighter loop within tracker-store, eg. helps reduce the time spent in processing the renaming of a linux kernel tree (51964 elements) from 23s to 12s. (as measured locally by tracker-miner-fs on a previously idle system). libtracker-data: Add support for BIND The BIND form allows a value to be assigned to a variable from a graph pattern: SELECT ?u ?hour { ?u a rdfs:Resource . nfo:fileLastModified ?modified BIND (HOUR (?modified) AS ?hour) } It will be specially useful on places where we use the result of a calculation on more than one places, eg. on SELECT and FILTER(). It will also be useful combined with DELETE...INSERT...WHERE to perform complex mass-updates in a single query. http://www.w3.org/TR/sparql11-query/#bind libtracker-data: Resolve variables looking up the binding if we're in same context This is necessary for BIND support, as the variables looked up to add the BIND alias likely belong to the same scope that we're currently building. This results in SQL like (very simplified, and shortened): SELECT "nie:url" AS "1_u", "1_u" AS "2_u" ... The second "1_u" can't be looked up yet in this scope (only on the WHERE clause, or a wrapping SELECT), so ends up as the string itself. With this change, this kind of queries will result in (shortened again): SELECT "nie:url" AS "1_u", "nie:url" AS "2_u" ... Which is legal, and results in the expected values assigned to the BIND alias. libtracker-data: Relate Variable objects to their origin Context It will be necessary so we can figure out at query construction time whether we are in a scope where we can use the variable alias or not. libtracker-data: Implement sparql1.1 delete/insert Sparql1.1 defines updates as a single statement of the form: DELETE {} INSERT {} WHERE {} With delete/insert-only syntax being special cases for that common form: http://www.w3.org/TR/sparql11-update/#deleteInsert This is now implemented in litracker-data, the parser will accept this new syntax, and perform the delete/insert operations on all solution items. We first perform all deletes and then all inserts in order to minimize database flushing. libtracker-data: Add support for NOW() builtin function This function is defined in Sparql 1.1 query language recommendation, http://www.w3.org/TR/sparql11-query/#func-now libtracker-data: Add support for RAND() builtin function This function is defined in Sparql 1.1 query language recommendation, http://www.w3.org/TR/sparql11-query/#idp2130040 libtracker-data: Add SparqlRand sqlite function This will be used to back up the RAND() sparql 1.1 function. Unlike the random() sqlite builtin function, g_random_double() gives us the random number in the same range than described in the recommendation, so it seems a better fit.