My Android app is using an SQLite FTS3 table to provide full text search. I'm using insertWithOnConflict with CONFLICT_REPLACE to update my database, inserting a new row if need be or updating an existing row if it's present.
I was very surprised to find that my table ended up containing duplicate rows — but it looks like this is a documented "feature" of SQLite's FTS modules:
From the SQLite FTS3 and FTS4 Extensions page:
Datatypes and column constraints are specified along with each column. These are completely ignored by FTS and SQLite.
It's pretty easy to replicate the duplication from the command line:
sqlite> CREATE VIRTUAL TABLE test_duplicates USING FTS3
...> (id INTEGER PRIMARY KEY, name TEXT);
sqlite> INSERT INTO test_duplicates (id, name) VALUES (1, "George");
sqlite> INSERT INTO test_duplicates (id, name) VALUES (1, "George");
sqlite> INSERT OR REPLACE INTO test_duplicates (id, name) VALUES (1, "George");
sqlite> SELECT * FROM test_duplicates;
1|George
1|George
1|George
sqlite>
My question is: what's the best (simplest, most robust) way to replicate the behaviour of CONFLICT_REPLACE?
My ideas at the moment are either to (A) do a SELECT, then an UPDATE or INSERT based on the result or (B) blindly try DELETE the existing row (which may or may not be present) and then INSERT.
refering to the fts document, i found this paragraph:
... each FTS table has a "rowid" column. The rowid of an FTS table behaves in the same way as the rowid column of an ordinary SQLite table, except that the values stored in the rowid column of an FTS table remain unchanged if the database is rebuilt using the VACUUM command. For FTS tables, "docid" is allowed as an alias along with the usual "rowid", "oid" and "oid" identifiers. Attempting to insert or update a row with a docid value that already exists in the table is an error, just as it would be with an ordinary SQLite table.
which means you could use the built-in docid column as your primary key and let the fts table apply it's constraint on it.