2015-12-17  Carlos Garnacho  <carlosg@gnome.org>

	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  <anders.jonsson@norsjovallen.se>

	Updated Swedish translation

2015-12-13  Matej Urbančič  <mateju@svn.gnome.org>

	Updated Slovenian translation

2015-12-10  Debarshi Ray  <debarshir@gnome.org>

	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  <carlosg@gnome.org>

	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.