Question

I am attempting to use foreign key support in SQLite to maintain referential integrity on a single-table database that has a reflexive join.

e.g.

PRAGMA foreign_keys = ON;

create table tree (
  objectId text unique not null,
  parentObjectID text,
  foreign key (parentObjectID) references tree(parentObjectID) on delete cascade
)

The behavior that I am hoping for is that when a parent row is deleted, its children and their children are deleted as well.

However, when I attempt to delete the root row (where the expected behavior would be that every other row in the database is also deleted), I get this error:

sqlite> delete from tree where objectid = '0';
Error: foreign key mismatch

Are my expectations out of whack with with SQLite foreign key support (and delete behaviors) can provide?

Answer 1

Your problem is pretty simple, your FK on parentObjectId references parentObjectId rather than objectId and SQLite doesn’t detect this bit of confusion until you try to use the table. If your FK is defined like this:

foreign key (parentObjectID) references tree(objectID) on delete cascade

From the fine manual:

So, in other words, misconfigured foreign key constraints that require looking at both the child and parent are DML errors. The English language error message for foreign key DML errors is usually “foreign key mismatch” but can also be “no such table” if the parent table does not exist. Foreign key DML errors are may be reported if:

• The parent table does not exist, or
• The parent key columns named in the foreign key constraint do not exist, or
• The parent key columns named in the foreign key constraint are not the primary key of the parent table and are not subject to a unique
  constraint using collating sequence specified in the CREATE TABLE, or
• The child table references the primary key of the parent without specifying the primary key columns and the number of primary key
  columns in the parent do not match the number of child key columns.

The third point would seem to apply here since parentObjectId is neither a PK nor constrained to be unique so that’s why you don’t see an error until you try to modify the table’s content (i.e. use a DML statement rather than a DDL statement).