[tracker/wip/carlosg/backports-3.3: 1/4] libtracker-sparql: Fix handling of partial FTS deletion

[Carlos Garnacho <carlosg src gnome org>]

commit 9017b74fdcd044ae66605250828bf4f66bdc8e73
Author: Carlos Garnacho <carlosg gnome org>
Date:   Wed May 4 20:39:56 2022 +0200

    libtracker-sparql: Fix handling of partial FTS deletion
    
    Due to the SQL interface offered to update external content
    and content-less FTS tables, updates on FTS columns must
    happen as 2 separate updates, one to delete tokenization
    data from the tree, and another to update.
    
    Due to our own current implementation details, the FTS
    table is synchronized per-row, meaning that we always want
    a FTS update after a FTS delete, in order to synchronize
    other properties properly. Fix the code to force one in
    place, instead of relying on loosely related paths to set it.
    
    This was unnoticed because most often FTS deletes are either
    a part of an FTS update, or part of a resource deletion (thus
    no FTS properties are left for the resource).
    
    But with the right circumstances, a FTS deletion may come
    alone, thus it would not trigger the later expected FTS
    update. This may unbalance the FTS tree, causing
    SQLITE_CORRUPT on later updates. An example of this is:
    
      INSERT DATA {
        <a> a nfo:InformationElement ;
          nie:title 'b' ;
          nie:identifier 'c' .
      }
    
      DELETE WHERE { <a> nie:title ?t }
    
    Fix this situation by always scheduling a FTS update after
    a delete. The FTS update will be opted out on actual full
    deletes otherwise (concretely by early out due to the FTS
    update having no actual changes).
    
    Fixes: https://gitlab.gnome.org/GNOME/tracker/-/issues/361
    
    (cherry-picked from commit cb82665dc9eee21f3aea38f4d55c1f48440f562e)

 src/libtracker-data/tracker-data-update.c | 1 +
 1 file changed, 1 insertion(+)
---
diff --git a/src/libtracker-data/tracker-data-update.c b/src/libtracker-data/tracker-data-update.c
index 1934a22e3..703de96c9 100644
--- a/src/libtracker-data/tracker-data-update.c
+++ b/src/libtracker-data/tracker-data-update.c
@@ -1693,6 +1693,7 @@ get_old_property_values (TrackerData      *data,
                                g_ptr_array_unref (fts_text);
 
                                old_values = g_hash_table_lookup (data->resource_buffer->predicates, 
property);
+                               data->resource_buffer->fts_updated = TRUE;
                        } else {
                                old_values = get_property_values (data, property, error);
                        }